Mencegah Efek Domino di Mikroservis dengan Circuit Breaker Pattern

Pernah nggak kalian ngalamin satu fitur minor di aplikasi—misalnya modul rekomendasi produk atau integrasi kurir pengiriman—mendadak lelet, tapi dampaknya malah bikin seluruh aplikasi ikut down total? Halaman checkout dan login utama pun jadi korban. 😅

Di arsitektur mikroservis, skenario mengerikan ini namanya cascading failure, alias efek domino kegagalan.

Ketika satu service hilir (downstream) lambat merespons, service hulu (upstream) bakal terus nunggu koneksi sampai batas timeout. Akibatnya ratusan thread dan koneksi server hulu terkunci, pool-nya kehabisan jatah, dan ujungnya ikut tumbang menyusul si service bermasalah.

Buat melindungi sistem dari bencana berantai ini, para arsitek software memasang pola legendaris bernama circuit breaker pattern (pemutus arus). Yuk, kita bedah gimana pola ini nyelametin backend kalian!

Kenapa Dinamain Circuit Breaker Sih?

Istilah circuit breaker diambil langsung dari dunia kelistrikan. Kalau di rumah kalian ada korsleting di colokan kulkas dapur, apa yang terjadi?

Tanpa sekring, arus berlebih bakal terus ngalir. Kabel di dalam dinding memanas, terbakar, dan akhirnya seluruh instalasi listrik rumah ikut hangus.

Dengan sekring, begitu sensornya mendeteksi lonjakan arus abnormal, tuasnya langsung "jeglek" (trip) dan memutus aliran ke area dapur. Lampu ruang tamu dan kamar tidur tetap menyala terang. Rumah kalian aman, nggak ikut hangus. 😄

Di dunia backend, circuit breaker bertindak persis kayak sakelar pengaman otomatis. Dia memutus panggilan ke service yang bermasalah sebelum service itu ngerusak seluruh ekosistem.

Pola ini dipopulerkan lewat artikel arsitektur Martin Fowler dan dipakai di banyak pustaka industri kayak Resilience4j serta Netflix Hystrix.

Tiga Status Utama Circuit Breaker

Circuit breaker bekerja kayak state machine dengan tiga kondisi utama.

Status Closed: Semuanya Adem

Di kondisi normal, sakelarnya tertutup dan aliran lancar. Semua request dari klien diteruskan langsung ke service target. Kalau sesekali ada error—misal 1 dari 100 request gagal—circuit breaker cuma nyatet metrik kegagalan tanpa memutus aliran.

Status Open: Langsung Fast-Fail

Kalau persentase kegagalan atau timeout melampaui batas toleransi—misalnya 50% request gagal dalam 10 detik terakhir—sakelarnya langsung pindah ke status Open.

Di status ini, panggilan ke service target diputus. Semua request berikutnya langsung digagalkan seketika (fast-fail), tanpa perlu nunggu network timeout 10–30 detik.

Sistem langsung menjalankan mekanisme cadangan (fallback): balikin data dari cache lama atau kasih pesan informasi yang ramah. Service yang bermasalah pun dapat ruang buat recovery, nggak dibombardir ribuan request baru terus-terusan.

Status Half-Open: Uji Coba Pelan-Pelan

Setelah batas waktu istirahat berlalu—misal 30 detik di status Open—sakelarnya pindah ke Half-Open.

Di sini, sistem ngizinin sejumlah kecil request percobaan (canary requests) buat manggil service target lagi. Kalau percobaannya sukses, service dianggap udah pulih dan sakelar balik ke Closed. Tapi kalau masih gagal, dia langsung balik ke Open dan ngreset waktu istirahatnya.

Fallback: Jangan Kasih Pesan Error yang Nakutin

Kunci keberhasilan pola ini ada di graceful degradation lewat respons cadangan (fallback). Pesan error yang serem cuma bikin pengguna panik dan kabur.

Kalau layanan rekomendasi down, tampilkan daftar produk default atau best-seller statis daripada ngerusak tata letak halaman beranda.

Kalau layanan kurir atau tarif ongkir down, tampilkan estimasi tarif flat sementara, dengan catatan kalkulasi detail bakal diperbarui saat checkout.

Kalau layanan rating dan ulasan down, sembunyikan dulu bagian ulasannya. Pengguna tetap bisa lihat deskripsi produk dan bertransaksi dengan tenang.

Contoh Implementasi di Python (FastAPI + PyBreaker)

Berikut contoh penerapan circuit breaker pakai pustaka PyBreaker dan HTTPX di Python:

import httpx
import pybreaker
from fastapi import FastAPI, HTTPException
from starlette.concurrency import run_in_threadpool

app = FastAPI()

# Konfigurasi Circuit Breaker:
# Trip ke Open jika 5 request berturut-turut gagal, coba lagi setelah 30 detik (reset_timeout)
payment_breaker = pybreaker.CircuitBreaker(
    fail_max=5,
    reset_timeout=30,
    name="PaymentGatewayBreaker"
)

def call_payment_gateway(order_id: str, amount: float):
    # Memanggil endpoint third-party payment gateway (sinkron, sesuai pybreaker)
    with httpx.Client(timeout=3.0) as client:
        response = client.post(
            "https://api.external-payment.com/v1/charge",
            json={"order_id": order_id, "amount": amount}
        )
        response.raise_for_status()
        return response.json()

@app.post("/api/checkout/{order_id}")
async def checkout(order_id: str, amount: float):
    try:
        # Jalankan panggilan di dalam perlindungan Circuit Breaker.
        # pybreaker.call() itu sinkron, jadi kita dorong ke threadpool
        # biar event loop FastAPI nggak ikut ngeblok.
        result = await run_in_threadpool(
            payment_breaker.call, call_payment_gateway, order_id, amount
        )
        return {"status": "success", "data": result}
    except pybreaker.CircuitBreakerError:
        # Sakelar sedang OPEN (Fast-Fail): Jangan tunggu timeout, langsung fallback!
        return {
            "status": "degraded",
            "message": "Gerbang pembayaran sedang dalam pemeliharaan berkala. Pesanan kalian sudah dicatat dan akan diproses otomatis begitu sistem pulih!",
            "order_id": order_id
        }
    except Exception as exc:
        raise HTTPException(
            status_code=502,
            detail=f"Terjadi kendala pada mitra pembayaran: {str(exc)}"
        )

Dengan pola di atas, saat server payment pihak ketiga lumpuh total, API checkout kalian nggak bakal ikut hang atau kehabisan koneksi. Klien langsung nerima respons informatif dalam hitungan beberapa milidetik, lho!

Jadi, Kenapa Ini Wajib Banget?

Di arsitektur terdistribusi yang kompleks, kegagalan komponen pihak ketiga atau service pendukung itu keniscayaan yang nggak bisa dihindari (failures are inevitable).

Alih-alih membiarkan satu titik kegagalan (single point of failure) melumpuhkan seluruh aplikasi, memasang circuit breaker pattern adalah pertahanan wajib. Sistem inti kalian tetap menyala, tangguh, dan elegan saat krisis datang.

Selamat ber-arsitektur ria, dan semoga satu service yang tumbang nggak pernah ngeruntuhin yang lain! 👋