Ketika layanan tujuan lambat atau gagal, request baru dapat terus menumpuk sampai thread, koneksi, dan memory habis. Circuit breaker menghentikan panggilan sementara setelah pola kegagalan tertentu, memberi dependensi waktu pulih, lalu menguji secara terbatas apakah layanan siap menerima trafik lagi.
Bagaimana tiga state circuit breaker bekerja?
Dalam state closed, request berjalan dan hasil diukur. Ketika ambang kegagalan terpenuhi, breaker menjadi open dan menolak panggilan baru dengan cepat. Setelah periode tertentu, half-open mengizinkan sejumlah kecil percobaan. Keberhasilan yang cukup menutup kembali; kegagalan membuka lagi.
Nama state sederhana, tetapi threshold harus mengikuti karakter dependensi. Satu error validasi bukan gangguan layanan. Timeout, koneksi gagal, 5xx tertentu, dan latency tinggi mungkin relevan. Klasifikasi perlu disepakati bersama kebijakan retry.
Parameter apa yang perlu dirancang?
| Parameter | Pertanyaan |
|---|---|
| Window | Berapa request atau waktu yang dinilai? |
| Minimum volume | Apakah satu gagal cukup untuk membuka? |
| Threshold | Rasio error atau latency berapa? |
| Open duration | Berapa lama sebelum probe? |
| Half-open limit | Berapa percobaan aman? |
Konfigurasi terlalu sensitif membuat layanan sehat sering ditolak; terlalu longgar membiarkan cascading failure berkembang. Gunakan data historis dan uji gangguan, bukan angka contoh sebagai default universal.
Apa yang dilakukan saat circuit terbuka?
Pilihan mencakup gagal cepat, mengembalikan cache dengan label usia, menerima pekerjaan asinkron, memakai layanan alternatif, atau meminta pengguna mencoba nanti. Fallback harus menjaga makna. Harga lama mungkin dapat ditampilkan untuk browsing, tetapi saldo pembayaran lama tidak boleh dipakai untuk keputusan settlement.
Nyatakan apakah hasil stale, perkiraan, atau belum final. Jangan mengubah kegagalan menjadi sukses semu hanya agar dashboard terlihat hijau.
Lihat bahaya sukses palsu.
Pada scope apa breaker dibuat?
Breaker global sederhana tetapi satu operasi buruk dapat memblokir semua. Scope per host, endpoint, tenant, atau kelas operasi dapat lebih presisi, namun membutuhkan volume cukup agar metrik bermakna. Pisahkan read dari write bila dampak dan karakter latensinya berbeda.
Dalam deployment terdistribusi, breaker lokal pada setiap instance dapat memiliki state berbeda. Breaker terpusat menambah koordinasi dan menjadi dependensi. Pilih scope sesuai blast radius serta tujuan kapasitas, lalu dokumentasikan apakah operator melihat satu state global atau beberapa state lokal.
Apa yang harus diamati dan diuji?
- Perubahan state beserta alasan dan waktu.
- Request yang ditolak cepat versus benar-benar gagal.
- Latency, error ratio, dan volume pada window.
- Keberhasilan serta kegagalan probe half-open.
- Dampak fallback terhadap hasil bisnis.
- Perilaku saat banyak instance pulih bersamaan.
Uji layanan lambat, 5xx, timeout, respons invalid, dan pemulihan bertahap. Masukkan prosedur manual ke runbook insiden.
Kapan circuit breaker bukan jawaban?
Jangan gunakan breaker untuk error bisnis permanen, input invalid, atau operasi lokal yang tidak memiliki dependensi. Jangan menambahkannya sebelum timeout dan resource limit jelas. Breaker juga tidak memberi rollback pada efek yang sudah terjadi dan tidak menghilangkan kebutuhan idempotensi setelah hasil tidak pasti.
Artikel ini membahas pola umum; tidak menyatakan bahwa NitroNet menerapkannya. Jika pola dibutuhkan di sekitar workflow, validasi dahulu melalui threat model dan budget timeout. Evaluasi NitroNet tetap didasarkan pada kemampuan publik dan bukti uji lingkungan Anda.
Jalankan eksperimen pada dependency tiruan agar tidak mengganggu pengguna. Buat latency dan error meningkat bertahap, lalu pulihkan layanan secara perlahan. Amati state, fallback, resource, dan pengalaman pengguna sepanjang siklus, bukan hanya apakah breaker pernah terbuka.
- Mulai dari volume di bawah minimum agar satu error tidak salah membuka circuit.
- Naikkan rasio timeout sampai threshold dan verifikasi alasan perubahan state dapat diaudit.
- Pastikan request saat open gagal cepat atau memakai fallback yang maknanya disetujui.
- Uji cache stale dengan label usia dan larang pengguna menganggapnya sebagai data final.
- Izinkan sedikit probe half-open dan cegah seluruh instance menyerbu dependency bersamaan.
- Pulihkan layanan sebagian lalu lihat apakah threshold menyebabkan open-close berulang.
- Uji operasi write dengan hasil tidak pasti dan pastikan breaker tidak menjanjikan rollback.
- Simpan timeline metrik, keputusan operator, serta perubahan konfigurasi setelah game day.
Breaker yang baik membatasi blast radius tanpa menyembunyikan kegagalan. Jika fallback menghasilkan keputusan salah, gagal cepat mungkin lebih aman. Parameter harus ditinjau dari volume dan latency nyata. Hapus breaker yang tidak memiliki pemilik atau observability karena state tersembunyi dapat memperumit diagnosis lebih daripada dependensi aslinya.
Uji breaker dengan gangguan terkontrol: respons lambat, koneksi ditolak, error parsial, dan layanan yang pulih bertahap. Amati kapan state membuka, berapa request percobaan pada half-open, serta apakah caller menerima alasan yang dapat ditindaklanjuti. Pastikan metrik membedakan penolakan oleh breaker dari kegagalan tujuan. Setelah pulih, periksa backlog dan lonjakan bersamaan karena penutupan breaker bukan bukti sistem sudah stabil. Runbook harus menjelaskan siapa yang boleh mengubah threshold dan bukti apa yang diperlukan sebelum override manual.