Breaker, bulkhead, dan membuang beban

Timeout dan retry mengatur satu panggilan. Tiga pola ini mengatur apa yang terjadi ketika sebuah dependensi sakit secara terus-menerus.

Circuit breaker punya tiga state

Closed ke open terjadi ketika laju kegagalan dalam satu jendela melewati ambang. Open ke half-open terjadi setelah menunggu. Half-open lalu kembali ke closed kalau percobaannya berhasil, atau langsung kembali ke open kalau tidak.

Half-open ada supaya pemulihan tidak menjadi gangguan kedua. Tanpa itu, breaker akan berpindah dari open langsung ke closed penuh dan melepaskan seluruh beban yang tertahan ke dependensi yang baru saja pulih — yang menumbangkannya lagi, dan sekarang kamu punya lingkaran. Segelintir panggilan percobaan menjawab “apakah dia benar-benar sudah membaik?” dengan biaya yang masih bisa ditanggung dependensinya.

State yang paling penting adalah open, dan yang perlu dipahami adalah dia melindungi siapa. Dia bukan untuk menaungi layanan yang gagal — layanan itu punya masalahnya sendiri. Dia untuk menghentikan thread milikmu mengantre ke sana, supaya bagian sistemmu yang tidak bergantung padanya tetap menjawab.

Bulkhead mengisolasi kerusakan

Bulkhead membatasi berapa banyak sumber daya yang boleh dihabiskan satu dependensi — biasanya jumlah panggilan bersamaan, kadang thread pool terpisah.

Kegagalan yang dicegahnya: satu dependensi lambat menjatuhkan seluruh service. Dengan satu pool bersama berisi 200 thread dan satu dependensi yang mulai memakan sepuluh detik, semua 200 thread berakhir menunggu di sana, dan request yang sama sekali tidak menyentuhnya sekarang ikut timeout. Batasi dependensi itu di 20 dan kerusakannya terbatas — panggilan itu gagal atau menunggu, dan sisanya tidak terpengaruh.

Namanya dari kapal: sekat-sekat, supaya lubang membanjiri satu ruang alih-alih seluruh lambung.

Membuang beban lebih baik daripada mengantre

Ketika kedatangan melebihi apa yang bisa diproses service, antreannya bertumbuh. Dua hal mengikutinya, dan keduanya lebih buruk dari yang terlihat:

Latensi bertumbuh tanpa batas sementara throughput datar. Service-nya sudah di kapasitas; mengantre tidak menambah kapasitas apa pun. Dia hanya menambah penungguan.

Sebagian besar isi antrean adalah pekerjaan yang tidak diinginkan lagi. Request yang sudah menunggu delapan detik kemungkinan besar terhubung ke klien yang sudah menyerah di detik ketiga. Kamu menghabiskan kapasitas menghitung jawaban untuk pemanggil yang sudah pergi — dan karena respons itu terbuang, antreannya justru terkuras lebih lambat lagi.

Membuang beban — menolak seketika dengan 429 atau 503 ketika antrean melewati batas — menjaga latensi pekerjaan yang diterima tetap stabil dan membiarkan pemanggil memutuskan: retry dengan backoff, menurunkan kualitas, atau memberi tahu penggunanya. Antrean berbatas dengan timeout pendek adalah bentuk praktis dari ini; antrean tanpa batas adalah gangguan yang ditunda.

Bagaimana semuanya berpadu

timeout       membatasi satu panggilan
retry         menangani kegagalan sesaat, dengan aman
bulkhead      membatasi berapa banyak yang boleh dihabiskan dependensi ini
breaker       berhenti memanggil sesuatu yang tumbang terus-menerus
shedding      melindungi service dari kotak masuknya sendiri

Tidak ada yang menggantikan yang lain, dan ada satu hal yang dibutuhkan semuanya: keputusan soal seperti apa jawaban yang menurun kualitasnya itu. “Gagal cepat” hanya berguna kalau gagal berarti sesuatu yang lebih baik daripada stack trace — harga dari cache, total kemarin, halaman yang tampil tanpa panel rekomendasi. Keputusan itu keputusan produk, dan justru itu yang paling sering dilewat.

Konfigurasi Resilience4j untuk kelimanya, dan insiden yang menghasilkan angka-angkanya: Referensi Pola Resilience4j.