Circuit Breaker Membatasi Panggilan Berulang ke Dependency yang Gagal

Dependency remote dapat gagal dengan cara yang lambat sekaligus mahal. Request menunggu timeout, worker tetap terpakai, retry menambah traffic, dan service lokal dapat kehilangan kapasitas walaupun kodenya sendiri tetap sehat.

Circuit breaker menempatkan keputusan berbasis state di depan jalur panggilan tersebut. Selama dependency bekerja dalam batas yang dapat diterima, panggilan diteruskan. Setelah kondisi kegagalan yang ditetapkan tercapai, breaker masuk ke state open dan menolak panggilan baru secara lokal selama periode terbatas. Setelah itu, sejumlah kecil probe diizinkan sebelum traffic normal dapat kembali.

Nilai utamanya bukan menghapus kegagalan. Breaker membatasi pekerjaan berulang terhadap dependency yang sudah menunjukkan tanda gangguan.

State closed mencatat bukti kegagalan

Breaker biasanya dimulai dalam state closed. Panggilan mencapai dependency dan hasilnya masuk ke policy. Policy dapat memakai kegagalan berturut-turut, rasio kegagalan dalam rolling window, ambang latency, atau kombinasinya.

Klasifikasi hasil perlu dibuat dengan cermat. Connection timeout atau HTTP 503 dapat menandakan gangguan dependency. Error dari caller seperti HTTP 400 biasanya tidak perlu masuk ke ambang kegagalan yang sama. Menganggap semua respons non-success sebagai kondisi identik dapat membuka breaker untuk kasus yang tidak akan pulih hanya dengan menunggu.

Ukuran sampling window juga memengaruhi perilaku. Rasio dari dua request terlalu mudah berubah, sedangkan window yang sangat besar bereaksi lambat. Implementasi sering menetapkan volume request minimum sebelum mengevaluasi ambang berbasis persentase.

State open menolak panggilan secara lokal

Setelah ambang terlampaui, breaker berpindah ke open. Panggilan baru gagal sebelum memakai connection, request slot, atau remote timeout budget.

Penolakan tersebut harus eksplisit. Caller dapat mengembalikan error, memakai data cache, memilih dependency lain, atau menjalankan fallback yang sesuai dengan produk. Breaker tidak otomatis membuat fallback menjadi benar; data stale atau parsial tetap memerlukan aturan semantik tersendiri.

Penolakan lokal juga perlu masuk observability. Jika metric hanya mencatat panggilan yang benar-benar mencapai dependency, breaker yang open dapat membuat traffic remote terlihat sehat ketika pengguna masih menerima kegagalan.

State half-open membatasi probe pemulihan

Membiarkan breaker tetap open selamanya akan mengubah gangguan sementara menjadi permanen. Setelah cooldown, breaker biasanya masuk ke half-open dan mengizinkan traffic probe dalam jumlah terbatas.

Batas tersebut penting. Jika seluruh request yang menunggu menjadi probe sekaligus, pemulihan dapat menghasilkan burst baru terhadap dependency yang baru saja mendapatkan kembali kapasitasnya. Probe budget yang kecil memberi bukti kondisi tanpa langsung mengembalikan load sebelumnya.

Probe yang sukses dapat menutup breaker. Probe yang gagal dapat mengembalikannya ke open dan memulai cooldown baru. Jumlah serta timing yang tepat merupakan pilihan policy, bukan konstanta universal.

Scope breaker harus presisi

Breaker dengan key terlalu luas dapat mengisolasi traffic yang sehat. Satu breaker global untuk seluruh platform eksternal dapat terbuka hanya karena satu endpoint atau region gagal. Sebaliknya, key yang terlalu sempit dapat menghasilkan ribuan state machine independen dengan traffic terlalu sedikit untuk memberi sinyal stabil.

Key yang berguna biasanya mengikuti failure boundary: dependency, kelas endpoint, region, partisi tenant, atau unit routing lain yang memiliki nasib kegagalan bersama.

Prinsip yang sama berlaku untuk connection pool dan replica. Jika request dapat dipindahkan dengan aman ke replica lain, state breaker tidak semestinya langsung menekan semua replica kecuali failure domain mereka memang sama.

Timeout dan retry budget tetap menjadi kontrol terpisah

Breaker bukan pengganti deadline. Panggilan yang diizinkan saat breaker closed tetap membutuhkan batas waktu connection dan response.

Breaker juga bukan retry policy. Melakukan retry beberapa kali sebelum mencatat satu hasil breaker dapat melipatgandakan tekanan pada dependency. Sistem biasanya mengoordinasikan retry budget, deadline, concurrency limit, dan state breaker agar satu mekanisme tidak memperkuat mekanisme lain.

Urutannya perlu disengaja. Metric sebaiknya membedakan attempt awal, retry, penolakan breaker, probe call, dan hasil akhir request.

Instance terdistribusi tidak harus memiliki state breaker identik

Setiap instance service dapat menyimpan state breaker sendiri. Pendekatan ini menghindari dependency koordinasi pada jalur kontrol kegagalan, tetapi setiap instance dapat membuka dan pulih pada waktu yang sedikit berbeda.

Perbedaan tersebut sering dapat diterima karena breaker merupakan mekanisme perlindungan lokal. Berbagi state dapat berguna pada arsitektur tertentu, tetapi menambah persoalan sinkronisasi, availability, dan state yang stale. Breaker yang konsisten secara global dapat berubah menjadi sistem terdistribusi tambahan yang harus tetap tersedia selama gangguan yang sedang dibatasinya.

Policy pemulihan membentuk traffic setelah gangguan

Menutup breaker segera setelah satu probe sukses dapat mengembalikan seluruh traffic lebih cepat daripada kemampuan dependency menyerapnya. Sistem dengan perubahan load tajam dapat menggabungkan half-open probing dengan pertumbuhan concurrency bertahap atau rate limit.

Karena itu, breaker perlu dinilai sebagai bagian dari keseluruhan admission path. Transisi state menentukan apakah panggilan boleh berjalan; transisi tersebut tidak menyatakan bahwa sistem downstream telah memiliki kapasitas pulih tanpa batas.

Breaker dengan scope yang tepat mengubah kegagalan remote berulang menjadi penolakan lokal yang terbatas, lalu menguji pemulihan dengan traffic terkendali. Kapasitas request yang langka tetap tersedia untuk pekerjaan yang masih memiliki jalur penyelesaian yang layak.