Graceful degradation เมื่อ dependency ล้มเหลวคืออะไร?

Question

Accepted Answer

**Graceful degradation** หมายความว่าเมื่อ dependency ล้มเหลว ระบบ **ยังคงให้ flow หลักทำงานได้** โดยเสิร์ฟประสบการณ์ที่ลดทอนหรือบางส่วนแทนที่จะคืน error เป้าหมายคือ **fail soft** ไม่ใช่ fail hard: หน้าที่ลดทอนยังดีกว่า 500

## เทคนิค

- **Fail soft** — เมื่อ dependency ล่ม ให้เสิร์ฟข้อมูลที่ **แคชไว้ บางส่วน หรือค่าเริ่มต้น** แทนที่จะ error ผลลัพธ์ที่ stale-แต่-มียังมักดีกว่าไม่มีอะไรเลย
- **Feature-flag ปิด path ที่ไม่สำคัญ** — ปิด recommendation, analytics, หรือ widget หรูหรา เพื่อให้ความล้มเหลวที่นั่นไม่ทำให้หน้าหลักพัง
- **Timeout + fallback** — อย่ารอ dependency ที่ช้าตลอดไป ให้ timeout แล้วสลับไปใช้ค่าหรือ path สำรอง
- **แยกความล้มเหลว (bulkhead)** — แบ่งทรัพยากร (thread pool, connection pool) ต่อ dependency เพื่อให้ service หนึ่งที่ล้มเหลวไม่ทำให้ทุกอย่างหมดและลากที่เหลือลงไปด้วย
- **ปกป้อง flow หลัก** — ระบุ path ที่ต้องทำงานได้ (browse, checkout) และรับประกันว่าฟีเจอร์ที่ไม่จำเป็นจะไม่มีวันทำให้มันล่ม

## ตัวอย่าง: search backend ล่ม

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

แทนที่จะเป็นหน้าที่ตายไป ผู้ใช้ได้รับผลลัพธ์ที่แคชไว้และคำแจ้งเตือนเล็ก ๆ ในขณะที่ navigation และ checkout ยังทำงานอยู่ ความล้มเหลวถูกจำกัดไว้ที่ฟีเจอร์เดียว

## ทำไมจึงสำคัญ

Dependency *จะ* ล้มเหลว — API ของบุคคลที่สาม, search cluster, recommendation service หากไม่มี graceful degradation ความล้มเหลวใด ๆ เพียงอันเดียวจะลุกลามกลายเป็น outage เต็มรูปแบบ การออกแบบให้ fail soft (ข้อมูลที่แคช/บางส่วน/ค่าเริ่มต้น) flag ปิด path ที่ไม่สำคัญ timeout พร้อม fallback และแยกความล้มเหลวด้วย bulkhead ทำให้ผลิตภัณฑ์ยังใช้งานได้ระหว่างความล้มเหลวบางส่วน — ซึ่งเป็นความแตกต่างระหว่างความผิดปกติเล็กน้อยกับ incident ใหญ่