Circuit Breaker Pattern: Mencegah Kegagalan Layanan Merambat

Dalam aplikasi yang bergantung pada beberapa API atau layanan eksternal, satu komponen yang lambat dapat menahan banyak permintaan dan menghabiskan koneksi yang tersedia. Jika aplikasi terus mencoba memanggil layanan yang sedang bermasalah, gangguan kecil bisa berkembang menjadi kegagalan yang lebih luas. Circuit breaker pattern membantu membatasi percobaan tersebut dengan menghentikan sementara panggilan ke komponen yang berulang kali gagal.

Pola ini terinspirasi dari pemutus arus listrik: ketika terdeteksi kondisi berbahaya, aliran diputus untuk mencegah kerusakan lebih besar. Dalam perangkat lunak, circuit breaker bukan alat untuk memperbaiki layanan yang rusak. Fungsinya adalah melindungi pemanggil, memberi waktu bagi layanan tujuan untuk pulih, dan menyediakan jalur penanganan kegagalan yang terencana.

Apa itu circuit breaker pattern?

Circuit breaker adalah mekanisme yang memantau hasil pemanggilan ke suatu dependensi, misalnya API pembayaran, layanan inventaris, atau basis data. Berdasarkan ambang kegagalan dan kebijakan yang ditentukan, mekanisme ini mengubah perilaku pemanggilan. Ketika sirkuit terbuka, permintaan baru ditolak atau dialihkan ke respons alternatif tanpa terus menunggu dependensi yang bermasalah.

Pola ini berbeda dari retry. Retry mencoba kembali operasi yang gagal, sedangkan circuit breaker membatasi kapan percobaan berikutnya boleh dilakukan. Keduanya dapat dipakai bersama, tetapi retry yang tidak dibatasi justru dapat menambah beban ketika layanan tujuan sedang kelebihan kapasitas.

Tiga keadaan utama

1. Closed: permintaan berjalan normal

Dalam keadaan closed, panggilan diteruskan ke layanan tujuan dan hasilnya dicatat. Jika tingkat kegagalan masih dalam batas yang ditentukan, sirkuit tetap tertutup. Ambang dapat berbasis jumlah kegagalan, rasio kegagalan dalam jendela waktu, atau kombinasi dengan durasi respons. Pilih ukuran yang sesuai dengan volume trafik; beberapa kegagalan pada trafik sangat rendah tidak selalu menunjukkan masalah sistemik.

2. Open: panggilan dihentikan sementara

Jika ambang terlampaui, sirkuit berpindah ke keadaan open. Selama periode ini, permintaan tidak dikirim ke dependensi yang sedang bermasalah. Aplikasi dapat mengembalikan pesan yang jelas, memakai data cache yang masih layak, menonaktifkan fitur opsional, atau memasukkan pekerjaan ke antrean bila desain sistem mendukungnya.

Respons alternatif harus sesuai konteks. Data lama mungkin dapat diterima untuk katalog produk, tetapi tidak untuk saldo rekening atau status pembayaran yang harus akurat. Jangan mengganti kegagalan dengan jawaban sukses palsu; respons harus menjelaskan keterbatasan tanpa membocorkan detail internal.

3. Half-open: menguji pemulihan

Setelah masa tunggu berakhir, sirkuit masuk ke keadaan half-open dan mengizinkan sejumlah kecil permintaan percobaan. Jika panggilan itu berhasil, sirkuit dapat kembali ke closed. Jika masih gagal, sirkuit kembali terbuka dan menunggu sebelum mencoba lagi. Pembatasan jumlah percobaan mencegah banyak instance aplikasi menyerbu layanan sekaligus ketika layanan baru mulai pulih.

Kapan pola ini berguna?

Circuit breaker cocok untuk panggilan jaringan yang memiliki batas waktu dan hasil kegagalan yang dapat dikenali, terutama pada arsitektur microservices atau integrasi API pihak ketiga. Contohnya, layanan rekomendasi dapat gagal tanpa harus membuat seluruh halaman produk tidak tersedia. Pemanggil dapat melewati rekomendasi untuk sementara, sementara fungsi inti tetap berjalan.

Pola ini tidak otomatis diperlukan untuk setiap fungsi. Untuk pemanggilan lokal yang sangat cepat, operasi yang selalu dapat diandalkan, atau pekerjaan yang memang harus diselesaikan secara konsisten, kompleksitas tambahan mungkin tidak sebanding dengan manfaatnya. Tentukan terlebih dahulu dampak kegagalan dependensi terhadap pengalaman pengguna dan kebutuhan bisnis.

Langkah penerapan yang praktis

1. Tetapkan timeout. Setiap panggilan ke dependensi harus memiliki batas waktu yang masuk akal. Tanpa timeout, permintaan dapat menggantung terlalu lama dan menghabiskan thread atau koneksi sebelum circuit breaker sempat mengambil keputusan.
2. Tentukan kegagalan yang dihitung. Timeout, koneksi terputus, dan respons server tertentu mungkin dihitung sebagai kegagalan. Kesalahan validasi dari pengguna biasanya tidak seharusnya membuka sirkuit, karena tidak menunjukkan dependensi sedang rusak.
3. Pilih ambang dan masa tunggu. Gunakan data latensi serta tingkat kegagalan aktual untuk menetapkan nilai awal. Hindari angka universal; trafik, toleransi gangguan, dan kemampuan pemulihan setiap layanan berbeda.
4. Rancang fallback. Tentukan perilaku aplikasi saat sirkuit terbuka. Jika tidak ada fallback yang aman, kembalikan kegagalan yang terkendali dan informatif daripada membiarkan permintaan menunggu tanpa batas.
5. Uji kondisi gangguan. Simulasikan timeout, respons gagal, dan pemulihan dependensi di lingkungan pengujian. Pastikan transisi antar-keadaan berjalan benar dan tidak memicu percobaan serentak berlebihan.

Hindari jebakan konfigurasi

Kesalahan umum adalah menganggap semua respons non-sukses sebagai kegagalan yang sama. Respons 400 akibat masukan yang salah berbeda dari timeout atau respons 503 dari layanan tujuan. Klasifikasikan hasil berdasarkan perilaku dependensi, bukan hanya kode status secara membabi buta.

Perhatikan pula interaksi dengan retry. Jika setiap permintaan mencoba ulang berkali-kali sebelum circuit breaker menghitung kegagalan, beban tambahan bisa menumpuk. Batasi jumlah retry, gunakan jeda bertahap dengan jitter, dan pastikan operasi aman untuk diulang. Untuk operasi yang mengubah data, gunakan mekanisme idempotensi bila tersedia.

Dalam sistem dengan banyak instance, tiap instance mungkin memiliki keadaan sirkuit sendiri. Ini biasanya cukup untuk perlindungan lokal, tetapi dapat membuat pola pemulihan tidak seragam. Pantau perilaku keseluruhan sistem dan hindari koordinasi terpusat yang justru menjadi titik kegagalan baru tanpa kebutuhan jelas.

Pemantauan dan observabilitas

Catat jumlah transisi ke open, jumlah permintaan yang ditolak oleh sirkuit, kegagalan saat half-open, serta waktu pemulihan. Metrik ini membantu membedakan apakah layanan tujuan masih bermasalah atau ambang circuit breaker terlalu sensitif. Kaitkan informasi tersebut dengan log dan trace agar tim dapat melihat dampaknya pada permintaan pengguna. Panduan OpenTelemetry untuk logs, metrics, dan traces dapat menjadi titik awal untuk merancang pemantauan lintas layanan.

Jangan menjadikan setiap perubahan keadaan sebagai peringatan berprioritas tinggi jika perubahan itu sering terjadi secara normal. Buat ambang alert berdasarkan dampak terhadap layanan dan tetapkan prosedur siapa yang menindaklanjuti. Informasi diagnostik juga harus bebas dari token, kredensial, dan data pribadi.

Kesimpulan

Circuit breaker membantu mencegah kegagalan satu dependensi menyebar ke bagian aplikasi lainnya. Keberhasilannya bergantung pada timeout, klasifikasi kegagalan, ambang yang sesuai, fallback yang jujur, serta pengujian pemulihan. Mulailah pada satu integrasi yang memang berisiko, ukur hasilnya, lalu perluas jika manfaatnya terbukti. Circuit breaker bukan pengganti perbaikan akar masalah, tetapi pagar pengaman agar gangguan dapat ditangani dengan lebih terkendali.