UNDER PRESSURE

Level 3 · Sistem yang Saling Bergantung

Sesi 25: Efek Domino: Cascading Failure, Timeout, & Circuit Breaker

Bagaimana jika satu layanan microservice kecil yang melambat selama 10 detik berhasil menyedot seluruh connection pool dan worker thread di 20 server upstream hingga meruntuhkan seluruh platform e-commerce dalam tempo kurang dari 2 menit?

Sesi 25 / 343 menit baca

1. Bayangkan Jika

Di sebuah kapal kargo raksasa berbobot ratusan ribu ton, lambung kapal dirancang tidak berupa satu ruangan kosong raksasa, melainkan disekat-sekat menjadi belasan kompartemen kedap air (Bulkhead). Jika lambung kapal menabrak karang dan satu kompartemen bocor terisi air, pintu sekat otomatis tertutup rapat. Hanya kompartemen itu yang basah, sementara kapal tetap mengapung normal.

Bayangkan jika kapal tidak punya sekat sama sekali: satu lubang paku kecil di ujung buritan akan membiarkan air mengalir perlahan ke seluruh ruangan, mematikan mesin utama, dan menenggelamkan seluruh kapal. Itulah Cascading Failure di sistem terdistribusi.

2. Apa yang Sebenarnya Terjadi

Ketika sebuah downstream service (misal: Payment Service atau Third-Party SMS Provider) mengalami kendala:

  1. Thread Starvation & Pool Exhaustion: - Upstream service (Order Service) mengirim request ke Payment. - Karena tidak ada batas waktu (No Timeout) atau timeout diset terlalu longgar (misal 30 detik), worker thread di Order Service tertahan menunggu (blocking IO). - Saat ada 200 request masuk bersamaan, seluruh 200 thread di Order Service habis terikat menunggu balasan Payment. - Akibatnya: Order Service berhenti merespons request lain (bahkan request baca yang tidak butuh Payment).

  2. Perambatan Efek Domino: - Karena Order Service membeku, API Gateway yang memanggil Order Service ikut kehabisan koneksi. - Karena API Gateway membeku, load balancer menganggap seluruh kluster down dan pengguna melihat layar error putih 504 Gateway Timeout. - Satu layanan kecil yang lambat menenggelamkan seluruh platform.

3. Senjata Penyelamat: Circuit Breaker & Bulkhead

Untuk memutus rantai kehancuran ini, arsitek memasang Circuit Breaker (seperti sekring listrik di rumah):

  1. Tiga Status Circuit Breaker: - CLOSED (Normal): Semua request dialirkan seperti biasa. Sistem mencatat rasio error/timeout. - OPEN (Trip / Putus): Jika kegagalan melampaui batas ambang (misal 50% request gagal/timeout dalam 10 detik), sirkuit langsung JEBOL. Semua request berikutnya langsung ditolak seketika (Fail-Fast dalam 0 ms) tanpa pernah menyentuh downstream yang sekarat! - HALF-OPEN (Uji Coba): Setelah masa istirahat (misal 30 detik), sirkuit mengizinkan beberapa request uji coba (probe). Jika sukses, sirkuit kembali CLOSED. Jika gagal, sirkuit kembali OPEN.

  2. Bulkhead Pattern (Isolasi Kolam Thread): - Pisahkan alokasi thread pool untuk masing-masing service hilir (misal: 50 thread untuk Catalog, 10 thread untuk SMS Provider). - Jika SMS Provider macet total, maksimal hanya 10 thread yang terkunci; 50 thread Catalog tetap bekerja 100% normal.

4. Nama Resminya

  • Cascading Failure: Rantai kegagalan di mana matinya satu komponen memicu kelebihan beban dan kematian pada komponen-komponen lain.
  • Circuit Breaker Pattern: Desain ketahanan sistem yang menghentikan eksekusi operasi yang berulang kali gagal untuk melindungi sistem.
  • Fail-Fast: Prinsip arsitektur di mana sistem mengembalikan respons kegagalan secepat mungkin daripada membiarkan klien menunggu.
  • Bulkhead Pattern: Pola isolasi sumber daya (thread, memory, connection pool) agar kegagalan satu area tidak merembet ke area lain.

5. Di Dunia Kita

  • Netflix Hystrix / Resilience4j: Pustaka standar industri untuk membungkus panggilan RPC dengan Circuit Breaker dan Bulkhead.
  • Envoy Proxy / Istio Service Mesh: Menyediakan Circuit Breaking otomatis di layer infrastruktur tanpa mengubah satu baris kode aplikasi pun.

6. Lensa Performance Tester

Metrik dan pengujian krusial: 1. Trip Threshold Verification: Suntikkan latensi 5 detik pada mock payment service saat beban 500 QPS. Verifikasi bahwa Circuit Breaker berpindah ke status OPEN dalam waktu <3 detik. 2. Fail-Fast Latency Check: Saat status OPEN, pastikan respons error fallback kembali dalam tempo <2 milidetik, bukan puluhan detik. 3. Half-Open Recovery: Pulihkan mock payment service dan pastikan sistem otomatis kembali ke status CLOSED tanpa perlu restart aplikasi.

7. Pertanyaan untuk Ronde Berikutnya

Ketika downstream service mengembalikan error, insting pertama developer sering kali adalah: "Coba lagi! (Retry!)".

Namun apa yang terjadi jika 10.000 smartphone pengguna mencoba me-retry request gagal secara bersamaan tepat saat server baru saja menyala kembali?

Bencana itu bernama Retry Storm. Jawabannya ada di Sesi 26: Ketika Semua Mencoba Lagi: Retry Storms, Jitter, & Backoff.