# सर्किट ब्रेकर और रिट्राई — सिस्टम डिज़ाइन

Source: https://www.geekswithgeeks.com/hi/system-design/sd-circuit-breaker

> समस्या को फैलाने के बजाय तेज़ी से विफल होना और उसे अलग करना।

## कैस्केडिंग विफलता की समस्या

जब कोई डाउनस्ट्रीम सेवा धीमी हो जाती है, कॉलर प्रतीक्षारत थ्रेड/कनेक्शन जमा करते हैं, जिससे वे भी धीमे हो जाते हैं — विफलता ऊपर की ओर फैलती है और पूरा सिस्टम गिरा सकती है।

## आपके घर का सर्किट ब्रेकर

बिजली के ब्रेकर की तरह, **सर्किट ब्रेकर** पैटर्न बार-बार विफलता के बाद **ओपन** हो जाता है — यह विफल सेवा को कॉल करना तुरंत बंद कर देता है (लटकते टाइमआउट के बजाय तेज़ विफलता), प्रतीक्षा करता है, फिर दोबारा बंद होने से पहले कुछ टेस्ट कॉल (**हाफ़-ओपन**) आज़माता है।

## बैकऑफ़ के साथ रिट्राई

अंधाधुंध तुरंत रिट्राई किसी अतिभारित सेवा को और बदतर बनाती है। घातांकीय रूप से बैकऑफ़ करें और जिटर जोड़ें ताकि सभी रिट्राई एक साथ न पहुँचें।

```text
delay = base * 2^attempt + random_jitter
if attempt > max_attempts: give up, fallback
else: sleep(delay); retry
```

Output:

```
Prevents retry storms from making an outage worse
```

## बल्कहेड्स और ग्रेसफुल डिग्रेडेशन

**बल्कहेड्स** हर डिपेंडेंसी को अपना थ्रेड पूल/कनेक्शन सीमा देते हैं ताकि एक धीमी डिपेंडेंसी बाकी की रिक्वेस्ट न भूखी रखे — जहाज़ के जलरोधक कक्षों की तरह। जब कोई गैर-महत्वपूर्ण डिपेंडेंसी डाउन हो, तो सुंदरता से घटें: पूरा पेज विफल करने के बजाय कैश्ड सिफारिशें दिखाएँ।