Circuit breaker — kapan berhenti mencoba
Setiap panggilan ke service lain bisa gagal — jaringan drop, service lain kelebihan beban, timeout. refleks pertama kita biasanya retry. Tapi retry di saat service yang dituju sedang sekarat justru menambah beban: request yang gagal dicoba lagi, antrean menumpuk, dan kegagalan menjalar ke pemanggilnya. Ini cascade failure.
Circuit breaker menyelesaikannya dengan logika sederhana: kalau tujuan terbukti sakit, berhenti mencoba. Gagal cepat, tunggu, coba hati-hati, lalu kembali normal.
Tiga keadaan breaker
- CLOSED — semua normal, request lewat. Yang dipantau: error rate dalam jendela tertentu (misal 10 request terakhir).
- OPEN — ambang terlampaui. Semua request ditolak instan tanpa menyentuh service yang sakit. Ini yang menyelamatkan sistem: sumber daya tidak habis untuk menunggu timeout.
- HALF-OPEN — setelah cooldown, breaker mengizinkan sedikit probe. Sukses beruntun → kembali CLOSED; gagal → OPEN lagi.
Mainkan sendiri
Simulasi di bawah menjalankan service dengan failure rate yang kamu tentukan. Naikkan rate di atas ambang 60% dan perhatikan urutannya: window terisi kegagalan → breaker trip (OPEN) → request berikutnya ditolak instan (lingkaran kosong) → cooldown → HALF-OPEN → pulih atau trip lagi.
SIMULASI INTERAKTIF
CLOSED
lalu lintas normal
OPEN
gagal cepat
HALF-OPEN
probe
← probe sukses → CLOSED
trip → request ditolak instan
window 10 · gagal 0 · ditolak 0 · total 0
Tanpa vs dengan breaker
Setiap request menunggu sampai timeout (misal 30 detik). Dengan 100 request/detik dan service sedang down, ada 3.000 request menggantung pada suatu saat — thread pool pemanggil habis, dan service yang sehat ikut tumbang.
Satu request, cerita penuh
Client memanggil service B lewat breaker yang sedang CLOSED.
Catatan implementasi
Beberapa hal yang menentukan breaker enak atau menyebalkan di production: pilih ambang dan window berdasarkan kapasitas pemanggil (bukan angka default library); gunakan cooldown yang berbeda untuk error klien vs infrastruktur; pastikan status breaker terekspos ke monitoring — breaker yang diam-diam OPEN adalah incident yang menunggu terjadi; dan sediakan fallback yang bermakna untuk setiap pemanggil, karena gagal cepat tanpa fallback hanya memindahkan kegagalan.
Pola ini tersedia di hampir semua stack: resilience4j (JVM), pybreaker/circuitbreaker (Python), Polly (.NET), opossum (Node). Yang penting bukan librarynya — tapi keputusan ambang, cooldown, dan fallback yang sesuai sistemmu.