Integrasi ERP dapat terlihat normal sampai satu layanan pendukung melambat. Permintaan menumpuk, pengguna menekan tombol lagi, dan worker terus mencoba mengirim transaksi. Jika setiap lapisan melakukan retry sendiri, gangguan yang semula terbatas dapat membebani sistem lain. Tim membutuhkan keputusan yang jelas tentang kapan mencoba lagi, kapan berhenti, dan bagaimana menjelaskan status pekerjaan kepada pengguna.
Circuit breaker aplikasi enterprise adalah pola untuk menghentikan sementara panggilan ke dependensi yang sedang berulang kali gagal. Pola ini relevan bagi kepala IT, arsitek solusi, dan pemilik proses yang mengelola ERP, portal B2B, serta integrasi layanan. Namun, memasang circuit breaker tidak otomatis menyelesaikan transaksi yang statusnya belum diketahui.
Panduan ini membahas keputusan desain, contoh alur, dan checklist pilot. Contoh merupakan skenario hipotetis; bukan hasil proyek atau janji ketersediaan layanan Layana.ID. Sasaran akhirnya adalah batas kegagalan yang dapat dijelaskan dan pemulihan yang dapat dibuktikan.
Apa yang Dilakukan Circuit Breaker?
Microsoft Azure Architecture Center menjelaskan tiga keadaan dasar. Pada closed, panggilan diteruskan dan kegagalan diamati. Pada open, panggilan ke dependensi ditolak sementara. Pada half-open, hanya sejumlah percobaan terbatas diteruskan untuk menilai pemulihan. Jika kondisi belum pulih, akses kembali dibatasi.
Microsoft juga membedakan circuit breaker dari retry: retry mencoba ulang kegagalan sementara, sedangkan breaker menghentikan percobaan yang kemungkinan masih gagal. Keduanya dapat digabung, tetapi retry harus menghormati keputusan breaker. Circuit breaker memberi ruang selama pemulihan; ia tidak memperbaiki layanan tujuan dengan sendirinya.
Dalam rancangan enterprise, pertanyaan berikutnya adalah apa yang terjadi pada pekerjaan bisnis ketika panggilan dibatasi. Apakah pengguna perlu menunggu, permintaan ditolak, atau pekerjaan dicatat sebagai antrean? Jawabannya harus disepakati bersama pemilik proses, bukan ditentukan hanya oleh nama library.
Tentukan Batas Kegagalan Berdasarkan Proses Bisnis
Mulai dari satu dependensi yang memiliki owner dan alur yang dapat ditelusuri. Contohnya, portal distributor mengirim permintaan reservasi stok ke ERP. Pisahkan operasi membaca katalog, memeriksa stok, dan membuat reservasi karena konsekuensi kegagalannya berbeda. Gangguan pembacaan informasi tidak boleh diam-diam menghasilkan konfirmasi transaksi.
Catat caller, layanan tujuan, lingkungan, jenis operasi, batas waktu pengguna, serta status yang mungkin tersimpan pada masing-masing sisi. Hubungkan peta itu dengan governance API enterprise agar perubahan kontrak dan ownership tidak terlepas dari pengelolaan integrasi.
- Pembacaan informasi: tentukan apakah cache boleh ditampilkan, berapa batas usia yang disetujui, dan bagaimana waktu pembaruannya dijelaskan.
- Permintaan transaksi: tentukan identitas permintaan, status penerimaan, dan cara memeriksa hasil sebelum mengirim ulang.
- Pekerjaan terjadwal: tetapkan batas antrean, owner pengecualian, dan tindakan jika pekerjaan melewati tenggat.
- Fungsi yang independen: pastikan gangguan satu integrasi tidak memblokir fungsi lain tanpa alasan bisnis.
Daftar tersebut adalah rekomendasi analisis. Implementasinya perlu menyesuaikan kontrak API dan fasilitas platform yang benar-benar tersedia. Jangan mengasumsikan semua vendor menyediakan pemeriksaan status transaksi atau kunci idempotensi.
Timeout, Retry Budget, dan Breaker Harus Selaras
Panduan Microsoft tentang transient fault handling menyarankan retry terbatas serta anggaran retry agregat. Batas per permintaan saja belum mengendalikan total percobaan dari banyak caller yang berjalan bersamaan. Panduan tersebut juga membahas backoff untuk memberi jeda ketika dependensi mengalami gangguan.
Untuk pilot perusahaan, dokumentasikan siapa yang menjadi pemilik retry. Jika gateway, SDK, aplikasi, dan worker semuanya memiliki retry, tim perlu menghitung percobaan yang benar-benar terjadi dari ujung ke ujung. Pemeriksaan konfigurasi setiap lapisan lebih berguna daripada hanya melihat satu angka pada kode aplikasi.
Parameter yang Perlu Dicatat
- Timeout: berapa lama caller menunggu hasil, termasuk batas total pekerjaan bila ada beberapa percobaan.
- Klasifikasi kegagalan: respons atau kondisi mana yang masuk perhitungan breaker dan mana yang membutuhkan koreksi permintaan.
- Jendela pengamatan: periode yang digunakan untuk mengevaluasi kegagalan, termasuk jumlah sampel yang dibutuhkan.
- Batas retry: percobaan maksimum, jeda, serta anggaran total pada dependensi yang sama.
- Periode open dan probe: kapan pemulihan diperiksa, berapa panggilan yang diperbolehkan, dan apa syarat kembali normal.
Tidak ada angka universal yang aman untuk seluruh ERP. Usulan awal harus didasarkan pada perilaku layanan, kebutuhan pengguna, dan hasil uji yang diizinkan. Tuliskan alasan setiap parameter serta sinyal yang akan membuat tim meninjaunya kembali. Hindari menyalin contoh konfigurasi dokumentasi menjadi janji operasional.
Timeout Transaksi Tidak Sama dengan Transaksi Gagal
Pada contoh reservasi stok, caller dapat berhenti menunggu setelah ERP menerima permintaan. Jika sistem langsung mengirim ulang tanpa memeriksa hasil, pemilik proses mungkin mendapatkan pekerjaan ganda. Karena itu, rekomendasi desain untuk mutasi adalah menyediakan referensi permintaan yang dapat ditelusuri dan membedakan status belum diketahui dari penolakan yang sudah pasti.
Jika layanan tujuan mendukung idempotensi, pastikan cakupan dan masa berlakunya dipahami. Jika tidak, tentukan prosedur pemeriksaan status atau rekonsiliasi yang realistis. Breaker yang sudah open tidak menjadi alasan untuk menyatakan seluruh transaksi sebelumnya batal.
Gunakan kontrol rekonsiliasi integrasi ERP untuk memeriksa pekerjaan yang tertunda, hilang, atau ganda. Artikel tersebut menangani kebenaran hasil transaksi; circuit breaker menangani pembatasan panggilan ketika dependensi bermasalah. Kedua tujuan perlu diuji secara terpisah.
Rancang Pesan Pengguna dan Fallback yang Jujur
Ketika integrasi tidak tersedia, pengguna tetap perlu tahu apa yang harus dilakukan. Pesan “berhasil” tidak boleh muncul hanya karena aplikasi sudah menyimpan permintaan lokal. Jika memang ada antrean yang andal dan disetujui, jelaskan bahwa permintaan diterima untuk diproses, bukan telah selesai di sistem tujuan.
Untuk contoh portal distributor, pesan dapat berbunyi: “Permintaan sudah tercatat dan menunggu pemeriksaan stok. Nomor referensi tersedia pada daftar permintaan. Konfirmasi reservasi belum diterbitkan.” Copy ini hanya sesuai bila aplikasi benar-benar menyimpan referensi dan menyediakan status tersebut.
Jika sistem tidak memiliki antrean, gunakan pesan penolakan yang jelas dan instruksi mencoba kembali sesuai kondisi. Jangan menampilkan stok lama sebagai ketersediaan pasti atau membuat hasil kosong terlihat seperti tidak ada pesanan. Fallback harus mempertahankan makna data, bukan sekadar membuat layar tampak sehat.
Pertanyaan untuk Owner Operasional
- Apakah pengguna boleh melanjutkan proses tanpa hasil dari dependensi ini?
- Siapa yang memeriksa pekerjaan tertunda dan bagaimana eskalasinya?
- Apakah ada tenggat bisnis yang membuat permintaan perlu dibatalkan atau ditinjau manual?
- Apakah status yang sama terlihat oleh pengguna, operator, dan tim integrasi?
Jawaban menentukan scope implementasi. Jika perusahaan belum memiliki proses penanganan pengecualian, siapkan proses itu sebelum mengaktifkan fallback otomatis pada transaksi penting.
Pemulihan Memerlukan Bukti pada Alur yang Dilindungi
Microsoft menjelaskan half-open sebagai cara membatasi percobaan saat layanan mulai pulih. Untuk acceptance pilot, tim perlu menentukan apa yang sebenarnya dibuktikan oleh percobaan tersebut. Endpoint umum yang merespons belum tentu menunjukkan operasi reservasi stok sudah dapat berjalan.
Rekomendasi praktisnya adalah memilih probe yang relevan dan aman. Pembacaan dapat diuji melalui operasi yang tidak mengubah data. Mutasi memerlukan skenario pada lingkungan uji atau mekanisme resmi yang tidak menciptakan transaksi produksi tanpa izin. Jangan memakai pesanan pelanggan sebagai probe eksperimen.
Amati bukan hanya status breaker, tetapi juga waktu respons, hasil operasi, antrean, dan status bisnis. Hubungkan sinyal dengan observability aplikasi enterprise. Tim perlu dapat membedakan panggilan yang gagal di layanan tujuan dari panggilan yang sengaja ditolak breaker.
Untuk pekerjaan yang tertahan, rancang pelepasan bertahap dan pemeriksaan hasil. Pulihnya koneksi tidak memberi alasan mengirim seluruh backlog sekaligus. Batas pemrosesan, tenggat, serta urutan yang diperlukan harus menjadi bagian dari keputusan owner proses.
Checklist Uji Pilot Sebelum Perubahan Produksi
Mulai pada staging atau lingkungan lain yang disetujui menggunakan data uji. Simulasi kegagalan produksi memerlukan otorisasi tersendiri. Checklist berikut merupakan rencana validasi; keberadaannya dalam artikel tidak berarti sistem perusahaan telah lulus.
- Alur normal: buktikan pekerjaan yang sah tetap mencapai hasil yang diharapkan ketika dependensi sehat.
- Dependensi lambat: periksa batas menunggu dan pastikan pengguna mendapat status yang sesuai.
- Kegagalan berulang: amati perubahan keadaan dan hitung apakah panggilan benar-benar berhenti sesuai aturan.
- Operasi independen: pastikan fungsi yang tidak membutuhkan dependensi tersebut tetap dapat digunakan.
- Hasil mutasi ambigu: uji pemeriksaan status sebelum pengiriman ulang dan periksa apakah ada duplikasi.
- Pemulihan terbatas: buktikan probe dibatasi dan kegagalan probe mengembalikan pembatasan.
- Backlog: periksa urutan, jumlah, tenggat, dan hasil pekerjaan yang dilanjutkan.
- Pemantauan dan rollback: pastikan owner memahami bukti, pengecualian, serta cara mengembalikan konfigurasi yang disetujui.
Acceptance harus memuat hasil teknis dan bisnis. “Breaker berubah menjadi closed” belum cukup apabila permintaan tertunda tidak dapat ditelusuri. Simpan referensi skenario, hasil, waktu, dan pihak yang menyetujui tanpa memasukkan token atau data pelanggan ke laporan.
Kapan Circuit Breaker Tidak Perlu Ditambahkan?
Microsoft menyebut sejumlah kondisi ketika pola ini mungkin tidak sesuai, termasuk saat retry yang tersedia sudah cukup atau pemulihan sudah dikelola platform. Karena itu, periksa kemampuan gateway, service mesh, SDK, dan broker sebelum menambah lapisan baru.
Untuk integrasi berbasis pesan, tinjau terlebih dahulu retry, batas antrean, dan penanganan pesan gagal yang sudah tersedia. Menambahkan breaker tanpa mengetahui perilaku broker dapat membuat tanggung jawab pemulihan kabur. Pilih mekanisme paling sederhana yang memenuhi risiko nyata dan dapat dioperasikan tim.
FAQ Circuit Breaker Aplikasi Enterprise
Apakah Circuit Breaker Menjamin Tidak Ada Downtime?
Tidak. Ia merupakan kontrol pembatasan panggilan. Gangguan sumber daya, kualitas konfigurasi, proses pemulihan, dan kebenaran transaksi tetap membutuhkan pemeriksaan tersendiri.
Apakah Semua Error Harus Membuka Breaker?
Tidak otomatis. Tim perlu membedakan permintaan yang tidak valid, masalah akses, dan gangguan dependensi berdasarkan kontrak layanan. Koreksi data atau izin mungkin lebih tepat daripada mencoba ulang.
Apakah Satu Breaker Bisa Dipakai untuk Semua Vendor?
Keputusan perlu mengikuti batas dependensi. Jika satu vendor bermasalah sementara vendor lain sehat, konfigurasi bersama dapat membatasi pekerjaan yang seharusnya tetap berjalan. Evaluasi cakupan berdasarkan operasi dan sumber daya yang dilindungi.
Siapkan Brief Pilot Integrasi
Untuk mendiskusikan circuit breaker aplikasi enterprise, siapkan satu alur prioritas: sistem pemanggil dan tujuan, operasi baca atau mutasi, volume dan pola penggunaan yang tersedia, batas menunggu, retry saat ini, status transaksi, owner, serta lingkungan uji. Sertakan contoh kegagalan yang sudah diamati; jangan mengirim kredensial atau data pelanggan.
Diskusikan pemetaan kebutuhan integrasi dengan Layana.ID untuk menyusun batas pilot, acceptance, dan keputusan implementasi. Mulai dari satu dependensi dengan hasil bisnis yang dapat diperiksa sebelum memperluas perubahan ke seluruh sistem.
Referensi Primer
Rujukan konsep: Microsoft Azure Architecture Center, Circuit Breaker pattern dan Transient Fault Handling. Nama sumber dicantumkan tanpa tautan keluar. Contoh portal distributor, brief pilot, checklist penerimaan, dan rekomendasi proses merupakan sintesis desain yang perlu disesuaikan dengan dokumentasi platform serta kebijakan perusahaan.