Circuit Breaker untuk Tim Engineering Indonesia: Cara Mencegah Satu Layanan Lambat Menjatuhkan Seluruh Sistem

TL;DR: Circuit Breaker adalah pola arsitektur yang melindungi aplikasi dari cascading failure saat layanan dependensi gagal. Setelah error rate menembus ambang, sirkuit terbuka dan permintaan ditolak cepat tanpa menunggu timeout. Untuk tim engineering Indonesia yang mengandalkan API pembayaran, pengiriman, dan AI eksternal, Circuit Breaker adalah salah satu kontrol uptime paling murah secara implementasi tetapi paling besar dampaknya.

Cerita yang sering saya dengar dari tim teknis Indonesia: API pihak ketiga lambat, timeout default 30 detik, request handler menumpuk, server memori penuh, dan seluruh website ikut down padahal layanan internal sehat. Kerugian seperti ini biasanya muncul justru di hari trafik puncak, momen yang seharusnya jadi panen. Pola Circuit Breaker dirancang untuk tepat skenario ini.

Kenapa Timeout Saja Tidak Cukup

Banyak engineer mengandalkan timeout untuk membatasi dampak layanan lambat. Masalahnya, timeout tetap memakan thread dan koneksi selama periode tunggu. Saat ratusan request masuk per detik dan layanan target lambat 10 detik, thread pool habis dalam beberapa puluh detik. Server sehat ikut tidak responsif. Dalam beberapa proyek terakhir saya menangani Atmo (LMS) dan Nalesha (e-commerce parfum), Circuit Breaker terbukti lebih efektif menjaga uptime dibanding sekadar mengetatkan timeout.

Bedakan dengan retry strategi. Retry mencoba lagi permintaan gagal. Circuit Breaker memutus permintaan baru saat layanan target jelas tidak sehat, mencegah retry storm yang justru memperberat masalah.

Anatomi Circuit Breaker

Tiga status utama yang wajib dipahami sebelum implementasi:

Konfigurasi umum: ambang 50% error dalam window 10 detik atau 20 permintaan terakhir, cooldown 30 detik. Untuk layanan kritikal seperti pembayaran, banyak tim memakai ambang lebih ketat (20-30%) dengan window lebih pendek.

Implementasi di Stack Indonesia

Node.js dan Next.js

Library opossum adalah pilihan paling populer. Bungkus pemanggilan API eksternal dalam circuit breaker, lengkapi dengan fallback yang mengembalikan data dari LLM cache atau Redis. Untuk Next.js App Router, letakkan logika ini di server action atau route handler, jangan di komponen client.

Python (FastAPI / Django)

Library pybreaker atau circuitbreaker cukup matang. Pasangkan dengan tenacity untuk retry yang sadar Circuit Breaker. Pastikan state circuit dishare antar worker via Redis kalau aplikasi berjalan di beberapa instance.

Microservices via API Gateway

Banyak gateway modern (Kong, Envoy, AWS API Gateway) sudah punya Circuit Breaker bawaan. Implementasi di level gateway memberi proteksi konsisten tanpa setiap layanan harus mengimplementasikan sendiri.

Lihat dokumentasi Microsoft soal pola Circuit Breaker untuk variasi konfigurasi yang lebih lengkap.

Studi Kasus: Atmo (LMS)

Saat membangun Atmo, kami mengandalkan layanan eksternal untuk verifikasi sertifikat dan transkode video. Kedua layanan ini kadang lambat di jam sibuk. Sebelum Circuit Breaker dipasang, satu episode lambatnya layanan transkode menyebabkan halaman dashboard pelajar lambat di seluruh platform karena thread sibuk menunggu. Setelah Circuit Breaker dipasang dengan ambang 40% error dan cooldown 45 detik, dampaknya terisolasi. Halaman dashboard tetap responsif, dan pelajar mendapat pesan "video sedang diproses" alih-alih spinner tanpa akhir.

Pelajaran kunci: Circuit Breaker tidak menyelesaikan akar masalah di layanan eksternal. Tugasnya adalah membatasi blast radius sehingga kegagalan satu layanan tidak menyeret seluruh sistem.

Anti-pattern yang Harus Dihindari

Tiga kesalahan yang sering saya temui saat audit kode tim Indonesia. Pertama, memasang Circuit Breaker tanpa fallback. Saat sirkuit terbuka, request gagal cepat, tapi pengguna tetap melihat error 500. Kedua, ambang batas terlalu longgar (90% error rate) sehingga sirkuit jarang terbuka padahal sistem sudah parah. Ketiga, tidak punya alert saat circuit beralih ke status Open. Tim baru tahu ada masalah saat dilaporkan pengguna.

Praktik Site Reliability Engineering yang sehat menempatkan Circuit Breaker sebagai bagian dari strategi resiliency menyeluruh, bukan tambalan setelah insiden.

Pertanyaan Umum

Apakah Circuit Breaker sama dengan rate limiting?

Tidak. Rate limiting membatasi permintaan masuk untuk melindungi sistem dari trafik berlebih. Circuit Breaker memutus permintaan keluar saat dependensi tidak sehat. Keduanya saling melengkapi, bukan saling menggantikan.

Apakah Circuit Breaker dibutuhkan untuk aplikasi kecil?

Ya, kalau aplikasi tersebut memanggil layanan eksternal kritikal seperti payment gateway atau API LLM. Skala bukan satu-satunya pertimbangan. Dependensi eksternal yang tidak bisa dikontrol jauh lebih menentukan.

Bagaimana cara menguji Circuit Breaker tanpa benar-benar menjatuhkan layanan?

Pakai chaos engineering tools seperti Toxiproxy untuk mensimulasikan latensi dan error pada layanan dependensi di lingkungan staging. Verifikasi sirkuit terbuka di waktu yang diharapkan dan fallback berjalan baik.

Berapa lama cooldown timer yang ideal?

Standar 30-60 detik untuk layanan internal. Layanan eksternal yang biasanya butuh waktu pulih lebih lama bisa 2-5 menit. Kalibrasi berdasarkan data historis recovery layanan target.

Penutup

Circuit Breaker adalah investasi kecil dengan return besar. Implementasinya bisa selesai dalam 1-2 sprint untuk satu layanan kritikal, tetapi efeknya terasa setiap kali dependensi eksternal bermasalah. Tim engineering Indonesia yang serius menjaga uptime tanpa membakar tim wajib menambahkan pola ini ke arsenal resiliency, bersama dengan error budget, dark launch, dan observability yang memadai. Sistem yang dewasa bukan sistem yang tidak pernah gagal, tapi sistem yang gagalnya kecil dan terisolasi.