Ketika jaringan kembali aktif, gangguan belum selesai. Pesan yang tertahan mulai berebut koneksi menuju database atau API yang baru pulih. Tanpa pengaturan laju dan prioritas, proses recovery dapat membuat tujuan overload, menambah retry, dan memperpanjang waktu pemulihan.
Mengapa pemulihan menciptakan lonjakan kedua?
Selama outage, mekanisme penyangga atau antrean dapat menahan pesan. Begitu koneksi pulih, banyak pesan dapat menjadi siap diproses hampir bersamaan. Pada waktu yang sama, trafik baru tetap masuk. Database tujuan mungkin sedang melakukan pemanasan, cache belum terisi, dan tim tujuan menjalankan pemeriksaan mereka sendiri.
Backlog juga tidak homogen. Status order lama mungkin masih wajib diproses berurutan; notifikasi promosi yang sudah lewat tanggal bisa dibuang; pembayaran memerlukan idempotensi ketat; update master data terbaru mungkin menggantikan update lama. Mengirim FIFO tanpa memahami semantik dapat menghasilkan keadaan yang salah walaupun semua request sukses.
Keputusan drain juga perlu memperhitungkan ketergantungan. Invoice item tidak boleh mendahului header, reservasi stok mungkin harus selesai sebelum status order berubah, dan laporan harian sebaiknya menunggu transaksi sumber stabil. Bila beberapa aliran berbagi database tujuan, kuota per workflow mencegah satu backlog besar mengambil seluruh connection pool. Prinsipnya bukan mengejar angka queue nol secepat mungkin, melainkan mengembalikan keadaan bisnis secara benar sambil menjaga trafik baru tetap berjalan. Setiap perubahan laju perlu memiliki kriteria penghentian ketika latensi atau error tujuan memburuk.
Klasifikasikan backlog sebelum mengurasnya
| Kelas pesan | Perlakuan | Kontrol |
|---|---|---|
| Transaksi kritis berurutan | Proses berdasarkan business key dan sequence | Idempotency key, ordering, serta rekonsiliasi |
| Update state yang dapat digabung | Ambil nilai terbaru bila aturan bisnis mengizinkan | Version/timestamp dan system of record |
| Pesan memiliki expiry | Hentikan atau arahkan ke review setelah kedaluwarsa | Expiry reason dan audit event |
| Best-effort notification | Prioritas lebih rendah dari proses inti | Rate limit, retention, dan channel policy |
Prioritas harus ditetapkan sebelum outage. Saat insiden, operator tidak memiliki waktu mempelajari arti setiap payload. Service tier, dependency, expiry, dan pemilik keputusan sebaiknya menjadi metadata workflow atau runbook yang mudah diakses.
Prosedur drain yang menjaga tujuan tetap sehat
- Bekukan perubahan non-esensial.
Hindari deployment dan replay manual saat baseline belum jelas. Catat backlog depth, oldest age, incoming rate, serta keadaan agent dan tujuan.
- Verifikasi tujuan dengan beban kecil.
Uji koneksi dan beberapa pesan representatif. Pastikan constraint, credential, schema, dan idempotency masih benar sebelum memperbesar concurrency.
- Naikkan laju secara bertahap.
Mulai di bawah kapasitas normal, pantau latency dan error tujuan, lalu naikkan batch/concurrency. Turunkan kembali ketika timeout, lock, atau retry ratio meningkat.
- Pisahkan pesan yang tidak aman.
Duplicate ambiguity, sequence gap, expired message, dan constraint permanen masuk jalur rekonsiliasi; jangan terus di-retry karena hanya menghabiskan kapasitas.
- Tutup recovery dengan control total.
Bandingkan count dan nilai kontrol antara sumber dan tujuan, periksa pesan dropped, lalu dokumentasikan jam kembali normal serta exception tersisa.
Dashboard saat backlog drain
Pantau dua kurva sekaligus: jumlah pesan masuk dan jumlah sukses keluar. Tambahkan oldest-message age, p95 latency tujuan, retry ratio, permanent failure, duplicate outcome, expired count, serta perkiraan waktu backlog habis. Depth yang turun tidak cukup bila pesan tertua tidak bergerak karena poison message.
- Rate drain memiliki batas awal, step kenaikan, dan kondisi stop.
- Owner tujuan menyetujui capacity serta indikator overload.
- Pesan expired dan permanen gagal keluar dari loop retry.
- Rekonsiliasi mencakup pesan lama serta trafik baru selama recovery.
Kontrol backlog dalam NitroNet
NitroNet menyediakan queue dan retry delivery, status attempt, health agent, serta node Throttle untuk mengatur laju proses. Rate Limit pada ingress memiliki tujuan berbeda: membatasi request yang masuk, bukan menguras antrean. Pelajari perbedaannya pada artikel Rate Limit endpoint dan perilaku saat jaringan offline.
API eksternal bersifat at-least-once dan perlu idempotency key. Ordering, expiry, serta kapasitas tujuan berasal dari aturan proses dan sistem tujuan; NitroNet tidak dapat menebaknya hanya dari isi antrean.
Siapkan runbook sebelum outage berikutnya
Jalankan latihan dengan menahan koneksi tujuan pada Sandbox, buat backlog terukur, kemudian pulihkan menggunakan tiga laju berbeda. Catat kapan latency memburuk dan berapa lama rekonsiliasi selesai. Hasilnya menjadi batas awal, bukan angka universal; kapasitas dapat berubah setelah schema, index, atau deployment tujuan berubah.
Simpan hasil latihan sebagai baseline capacity review berikutnya, lengkap dengan volume, konfigurasi, dan batas tujuan ketika pengujian dilakukan.
Tetapkan dashboard dan alert melalui observability NitroNet, tetapi pastikan setiap indikator memiliki tindakan. Oldest age tinggi memicu eskalasi; permanent constraint menghentikan retry; expired message masuk review bisnis. Recovery selesai ketika backlog aman, tujuan sehat, dan data dapat direkonsiliasi—bukan hanya ketika angka antrean mencapai nol.