Memahami Circuit Breaker: Solusi Mencegah Kegagalan Sistem Beruntun

Pendahuluan

Pernah mengalami aplikasi tiba-tiba down padahal kode kita baik-baik saja? Usut punya usut, ternyata API third party yang kita tembak sedang lambat.

Sebagai developer, menjaga kestabilan sistem adalah tantangan yang cukup membuat sakit kepala. Belakangan ini saya banyak memikirkan bagaimana merancang arsitektur yang aman untuk integrasi pihak ketiga.

Video dari Programmer Zaman Now tentang circuit breaker ini sangat membuka wawasan. Konsep ini ternyata sangat krusial agar aplikasi kita tidak ikut hancur saat sistem orang lain sedang bermasalah.

Masalah yang Ingin Diselesaikan

Pada arsitektur sistem tradisional, aplikasi kita biasanya akan setia menunggu balasan dari API eksternal. Jika API tersebut lambat, aplikasi kita akan terus menambah antrian request.

Bayangkan jika kita mengirim 100 request per detik, tapi third party hanya sanggup memproses 20 request. Sisa 80 request akan tertahan dan response time meningkat secara eksponensial.

Antrian yang menumpuk ini pada akhirnya akan memenuhi memori server. Hasil akhirnya tragis, justru aplikasi kita yang akan mati atau down, bukan aplikasi third party tersebut.

Kenapa Circuit Breaker Lebih Efisien?

Dibandingkan dengan metode request konvensional yang pasrah menunggu proses backend, pendekatan ini jauh lebih tangguh.

Berikut beberapa keuntungan utamanya:

mengurangi beban server karena tidak ada antrian panjang di memori.
request lebih cepat ditangani melalui mekanisme fail fast.
lebih scalable saat ada lonjakan traffic mendadak.
backend tidak menjadi bottleneck akibat menunggu layanan eksternal.

Konsep Dasar

Konsep ini meminjam mekanisme perlindungan yang sama persis dengan meteran listrik di rumah kita.

Jika daya listrik rumah hanya 3500 watt dan kita memaksa menyalakan alat 5000 watt, maka sirkuit akan jeglek atau terbuka. Aliran listrik langsung diputus untuk mencegah kebakaran rumah.

Di dunia programming, jika response time third party melewati batas toleransi, sirkuit akan diputus. Semua request baru akan langsung ditolak dan dikembalikan ke user tanpa perlu membebani sistem.

Gambaran Arsitektur

Alur sistem memiliki tiga status utama yaitu CLOSE, OPEN, dan HALF-OPEN.

Saat normal, statusnya CLOSE dan data mengalir biasa. Jika error melampaui batas, status menjadi OPEN dan request langsung di-drop selama jangka waktu tertentu.

Setelah jeda waktu habis, status berpindah ke HALF-OPEN untuk melakukan uji coba mengirim sebagian kecil request. Jika terbukti aman, sistem kembali ke CLOSE.

CODE

  [Aplikasi Kita] --(Request)--> [Circuit Breaker] --(Kirim)--> [Third Party]
                                        |
                                  +-----------+
                                  |  Status:  |
                                  |  1. CLOSE |
                                  |  2. OPEN  |
                                  |  3. HALF  |
                                  +-----------+

Implementasi

Sangat tidak disarankan membuat sistem ini dari nol secara manual. Mengatur perhitungan batas error dan time window itu cukup rumit.

Kita bisa menggunakan library open source yang sudah teruji, misalnya library opossum untuk environment Node.js.

Berikut adalah contoh praktis penggunaannya:

CODE

const CircuitBreaker = require("opossum");

// 1. Fungsi utama untuk nembak third party
const fetchExternalAPI = async () => {
  // Logika HTTP request ke layanan eksternal
};

// 2. Konfigurasi batasan toleransi
const options = {
  timeout: 5000, // Batas respons 5 detik, lebih dari itu hitung error
  errorThresholdPercentage: 50, // Buka sirkuit jika 50% request gagal
  resetTimeout: 60000, // Tunggu 60 detik sebelum masuk fase HALF-OPEN
};

// 3. Inisialisasi circuit breaker
const breaker = new CircuitBreaker(fetchExternalAPI, options);

// 4. Siapkan fallback jika sirkuit sedang OPEN
breaker.fallback(() => {
  return { status: "error", message: "Maaf, layanan partner sedang sibuk." };
});

// 5. Eksekusi request
breaker.fire().then(console.log).catch(console.error);

Dengan kode di atas, library akan otomatis memantau kecepatan response. Jika terjadi masalah di sisi third party, fungsi fallback akan langsung dijalankan.

Kesalahan Umum

Hal yang sering salah dipahami adalah mencoba menghentikan request dari sisi user. Padahal kita tidak mungkin bisa mencegah user menekan tombol di aplikasi.

Kesalahan lainnya adalah lupa menyiapkan fungsi fallback saat sirkuit sedang berstatus terbuka. Hal ini akan membuat aplikasi mereturn blank screen.

Solusinya, selalu siapkan data alternatif. Misalnya jika API saldo e-wallet sedang down, kembalikan nilai minus satu dan beri pesan bahwa layanan sedang dalam perbaikan agar user paham.

Refleksi Developer

Awalnya saya cukup bingung dengan istilah OPEN dan CLOSE. Ternyata dalam konteks ini, OPEN berarti sirkuit terputus dan koneksi dihentikan, sama seperti saklar lampu.

Insight terbesar yang saya dapat adalah kadang mematikan sebagian fitur sementara waktu jauh lebih elegan daripada memaksa sistem menunggu hingga berujung crash total.

Ini menjadi catatan penting untuk pengembangan Kulikanque ke depannya. Terutama sebagai persiapan jika nanti blog ini mulai memiliki banyak fitur yang terintegrasi dengan layanan eksternal.

Kesimpulan

Sistem ini adalah pelapis pertahanan yang wajib dimiliki oleh aplikasi berskala besar. Ia bertugas mencegah efek domino yang bisa mematikan server kita akibat kesalahan sistem lain.

Pilih library yang tepat, tentukan batas waktu yang rasional, dan selalu buat skenario respons cadangan agar pengalaman pengguna tetap terjaga dengan baik.