جب کوئی dependency ناکام ہو تو graceful degradation کیا ہے؟

Question

Accepted Answer

**Graceful degradation** کا مطلب یہ ہے کہ جب کوئی dependency ناکام ہو، تو سسٹم **بنیادی flow کو کام کرتا رہتا ہے** اور error واپس کرنے کی بجائے ایک محدود یا جزوی تجربہ فراہم کرتا ہے۔ مقصد یہ ہے کہ **نرمی سے ناکام ہو**، سخت انداز سے نہیں: ایک خراب شدہ page 500 سے بہتر ہے۔

## تکنیکیں

- **Fail soft** — جب کوئی dependency down ہو، تو **cached، جزوی، یا default** ڈیٹا فراہم کریں بجائے error دینے کے۔ ایک پرانا لیکن موجود نتیجہ عام طور پر کچھ نہ ہونے سے بہتر ہے۔
- **Feature-flag off غیر ضروری paths** — recommendations، analytics، یا فینسی widgets بند کریں تاکہ یہاں ناکامی سے main page ٹوٹ نہ سکے۔
- **Timeouts + fallbacks** — کبھی بھی کسی سست dependency پر ہمیشہ کے لیے انتظار نہ کریں؛ timeout کریں اور fallback value یا path پر سوئچ کریں۔
- **Failures کو isolate کریں (bulkheads)** — resources (thread pools، connection pools) کو ہر dependency کے لیے الگ کریں تاکہ ایک ناکام service دوسری تمام چیزوں کو exhaust نہ کر سکے اور انہیں نیچے نہ گھسیٹ سکے۔
- **Core flow کو محفوظ رکھیں** — لازمی کام کرنے والے path (browse، checkout) کو شناخت کریں اور یقینی بنائیں کہ غیر ضروری features کبھی بھی اسے نیچے نہیں لا سکتے۔

## مثال: search backend down ہے

```text
BAD  (fail hard):
  search() → backend timeout → throw → user sees HTTP 500 (whole page dead)

GOOD (fail soft):
  result = search()
         catch timeout → return cached_results OR empty + notice
  page renders:
    [ "Showing recent results — live search is temporarily unavailable." ]
    + cached listings, working nav, working checkout
  → user keeps browsing; core flow intact
```

مردہ page کی بجائے، صارف کو cached نتائج اور ایک چھوٹی اطلاع ملتی ہے، جبکہ navigation اور checkout کام کر رہے ہوتے ہیں۔ ناکامی ایک feature تک محدود ہے۔

## یہ اہم کیوں ہے

Dependencies *ضرور* ناکام ہوں گی — third-party APIs، search clusters، recommendation services۔ Graceful degradation کے بغیر، کوئی بھی ایک ناکامی مکمل outage میں تبدیل ہو سکتی ہے۔ نرمی سے ناکام ہونے کے لیے ڈیزائن کرنا (cached/partial/default ڈیٹا)، غیر ضروری paths کو flag کرنا، timeouts کے ساتھ fallbacks لگانا، اور failures کو bulkheads سے isolate کرنا — یہ سب partial failures کے دوران product کو استعمال میں رکھتا ہے — جو ایک معمولی مسئلہ اور بڑے incident کے درمیان فرق ہے۔