ما هي الحد من التدهور بشكل متوازن عند فشل أحد التبعيات؟

Question

Accepted Answer

**Graceful degradation** يعني أنه عند فشل أحد التبعيات، يحافظ النظام على **استمرار التدفق الأساسي** من خلال تقديم تجربة مخفضة أو جزئية بدلاً من إرجاع خطأ. الهدف هو **الفشل بسلاسة** وليس **الفشل الكامل**: صفحة متدهورة أفضل من 500.

## التقنيات

- **فشل سلس** — عند انقطاع التبعية، قدّم بيانات **مخزنة مؤقتاً أو جزئية أو افتراضية** بدلاً من إرجاع خطأ. النتيجة القديمة الموجودة عادة أفضل من لا شيء.
- **إيقاف المسارات غير الضرورية عبر feature-flag** — أوقف التوصيات أو تحليلات الاستخدام أو الأدوات الفاخرة حتى لا يؤثر الفشل هناك على الصفحة الرئيسية.
- **انتظار محدود + بدائل** — لا تنتظر إلى الأبد من تبعية بطيئة؛ انتظر مدة محددة ثم انتقل إلى قيمة أو مسار بديل.
- **عزل الأعطال (bulkheads)** — قسّم الموارد (thread pools وconnection pools) لكل تبعية بحيث لا يمكن لخدمة واحدة فاشلة أن تستنزف كل شيء وتسحب الباقي.
- **حماية التدفق الأساسي** — حدّد المسار الذي يجب أن يعمل (التصفح والدفع) وتأكد من أن المميزات غير الضرورية لا يمكنها أن تسقطه.

## مثال: محرك البحث معطل

```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
```

بدلاً من صفحة ميتة، يحصل المستخدم على نتائج مخزنة مؤقتاً وإشعار صغير، بينما التصفح والدفع يستمران في العمل. الفشل محصور في ميزة واحدة فقط.

## لماذا هذا مهم

التبعيات *ستفشل* — واجهات برمجية خارجية وclusters البحث وخدمات التوصيات. بدون graceful degradation، أي فشل واحد ينتشر ويسبب انقطاعاً كاملاً. التصميم للفشل السلس (بيانات مخزنة مؤقتاً أو جزئية أو افتراضية)، وإيقاف المسارات غير الضرورية، والانتظار المحدود مع بدائل، وعزل الأعطال باستخدام bulkheads يبقي المنتج قابلاً للاستخدام أثناء الأعطال الجزئية — وهذا هو الفرق بين عطل بسيط وحادث كبير.