Mati Listrik di Sistem Backend: Memahami Circuit Breaker

Ada satu momen ketika saya lagi ngulik integrasi third-party API... dan tiba-tiba aplikasi saya down.

Padahal kodenya sudah benar. Padahal servernya aman.

Usut punya usut, ternyata API tetangga yang lagi lemot. Tapi kok, aplikasi saya yang ikutan mati?

Dari situ saya sadar satu hal sederhana:

Sistem kita bisa hancur hanya karena menunggu jawaban dari sistem lain yang kelelahan.

Efek Domino Respons Lambat

Awalnya saya mikir: "Kalau API orang lemot, ya udah, user tinggal nunggu aja kan?"

Ternyata tidak sesederhana itu.

Misal aplikasi kita biasa ngirim 100 request per detik. Tapi third-party yang kita tembak cuma sanggup proses 20 request.

Apa yang terjadi?

• 20 request pertama aman (1 detik).
• 20 request kedua ngantri (jadi 2 detik).
• 20 request selanjutnya makin lama (jadi 3 detik).
• ...dan terus naik secara eksponensial.

Kalau ini dibiarkan, koneksi numpuk. Memori aplikasi kita bakal habis cuma buat nyimpen request yang lagi ngantri. Akhirnya? Out of Memory. Aplikasi kita yang mati.

Di sinilah kita butuh strategi.

Masuklah Circuit Breaker

Strategi ini mirip banget sama meteran listrik di rumah.

Kalau pemakaian listrik kita melebih kapasitas (misal cuma 3500 watt tapi pakai 5000 watt)... Meteran listrik akan jeglek. Terbuka (Open). Listrik mati.

Tujuannya? Mencegah kerusakan lebih parah.

Di backend, konsepnya sama:

• Closed: Semua aman. Request diteruskan ke third-party.
• Open: Kalau response time third-party sudah lewat batas wajar (misal terus-terusan di atas 5 detik), jalur kita putus.

Kita berhenti ngirim request. Semua langsung di-drop.

Kenapa di-drop? Biar request tidak numpuk di memori kita. Kita bisa langsung ngasih respons fallback ke user. Misal: balikin nilai negatif, kasih pesan "Sistem pembayaran sedang sibuk", atau ambil data dari cache.

Pemanasan: Half-Open State

Lalu kapan jalurnya dibuka lagi?

Masa kita harus buka tutup circuit secara manual?

Ternyata ada state ketiga: Half-Open.

Setelah beberapa waktu di state Open (misal 60 detik diam), sistem akan mencoba ngirim sedikit request. Anggaplah cuma 10% dari total request.

• Kalau response time-nya masih lambat -> Balik lagi ke Open.
• Kalau response time-nya sudah normal di bawah threshold -> Balik ke Closed. Semua request dialirkan 100% lagi.

Sistem warming up ini yang bikin aplikasi kita bisa pulih perlahan tanpa panik.

Jangan Bikin Sendiri

Awalnya saya merasa tertantang buat bikin logic ini dari nol.

Tapi nyatanya, state management dari Closed ke Open ke Half-Open itu lumayan ribet. Ada perhitungan time window, deteksi threshold, persentase request...

Kadang jadi engineer itu bukan soal bisa bikin semuanya sendiri, tapi tahu kapan pakai alat yang sudah ada.

Sekarang, sudah banyak library bagus. Kalau pakai Java ada Resilience4j. Di ekosistem Golang, Node.js, atau bahasa lain juga sudah melimpah.

Fokus saja ke pekerjaan utama kita dan business logic, biarkan library yang pegang kendali "listriknya".

Untuk Siapa Tulisan Ini?

Untuk saya sendiri kalau suatu hari nanti lupa lagi kenapa microservices saya saling menjatuhkan. Untuk siapa pun yang lagi bingung kenapa aplikasinya mati padahal API orang lain yang bermasalah.

Sistem yang hebat bukan cuma yang bisa jalan cepat ketika semuanya normal. Tapi sistem yang tahu caranya gagal dengan anggun.

Mari ngulik sesuatu.

---

Referensi

Circuit Breaker - Senior Programmer Wajib Ngerti - Programmer Zaman Now