Retry berguna ketika penyebab gagal bersifat sementara, seperti koneksi terputus singkat atau service sedang membatasi trafik. Namun mengulang request yang salah tidak membuatnya menjadi benar. Tanpa klasifikasi error dan idempotensi, retry justru dapat menambah beban, memperpanjang antrean, atau membuat data duplikat.
Retry hanya membeli kesempatan kedua
Kegagalan sementara dapat pulih tanpa perubahan payload: timeout jaringan, koneksi database yang sesaat tidak tersedia, HTTP 429, atau HTTP 503. Retry memberi waktu bagi dependensi untuk kembali siap. Sebaliknya, field wajib kosong, tipe salah, constraint dilanggar, token tidak valid permanen, atau tabel tidak ditemukan membutuhkan perbaikan data atau konfigurasi.
Mengulang error permanen menghasilkan pekerjaan tanpa kemajuan. Ia menggunakan kapasitas worker dan tujuan, menunda pesan lain, serta memenuhi log dengan error yang sama. Karena itu, sistem perlu mencatat apakah error retryable dan mengapa keputusan tersebut dibuat.
Klasifikasikan sebelum menjadwalkan ulang
| Contoh error | Keputusan awal | Tindakan |
|---|---|---|
| Timeout atau koneksi putus | Mungkin retry | Backoff, cek idempotensi |
| HTTP 429 | Retry | Hormati Retry-After |
| HTTP 400/validasi | Jangan retry | Perbaiki payload |
| Duplicate key | Tergantung maksud | Deteksi duplikat atau konflik |
| Unauthorized | Terbatas | Refresh kredensial lalu satu retry terkontrol |
Status HTTP membantu, tetapi tidak cukup. Sebagian API memakai HTTP 500 untuk kesalahan input, sementara sebagian lain memberi HTTP 200 dengan status gagal di body. Adapter perlu memahami kontrak tujuan dan menjaga detail teknis agar operator dapat menilai keputusan.
Kebijakan retry yang sehat
- Tentukan error retryable.
Gunakan kode terstruktur dan kategori koneksi, rate limit, autentikasi, constraint, atau konfigurasi.
- Terapkan backoff.
Jangan mengirim ulang secara rapat ketika tujuan sedang bermasalah.
- Batasi percobaan dan retensi.
Pesan tidak boleh berputar selamanya tanpa keputusan operasional.
- Gunakan identitas stabil.
Idempotency key atau kunci bisnis melindungi tujuan dari efek ganda.
- Catat setiap hasil.
Attempt, waktu, error terakhir, dan jadwal berikutnya harus dapat ditelusuri.
Contoh keputusan pada workflow invoice
Jika koneksi database tidak tersedia sebelum instruksi diproses, pesan dapat dijadwalkan ulang. Jika database menolak status karena check constraint, payload yang sama akan selalu gagal; workflow harus mengembalikan informasi nilai yang ditolak dan aturan yang relevan. Jika respons insert hilang setelah commit, retry tanpa identitas stabil dapat membuat invoice kedua.
Untuk API eksternal, efek bersifat at-least-once. Gunakan idempotency key yang sama pada setiap percobaan bila API mendukungnya. Untuk login token yang kedaluwarsa, refresh atau login ulang sekali secara terkoordinasi dapat dilakukan, tetapi retry autentikasi tanpa batas berisiko menciptakan login storm.
Apa yang terjadi setelah batas retry?
Pesan yang tidak berhasil selama masa retensi harus berubah menjadi status gagal atau dropped yang terlihat, bukan menghilang. Operator memerlukan error terakhir, node dan tujuan terkait, jumlah attempt, serta correlation ID. Keputusan berikutnya dapat berupa perbaikan konfigurasi, replay terkontrol, koreksi data, atau penghentian permanen.
Saat mengevaluasi NitroNet atau platform integrasi lain, uji apakah kegagalan dapat diklasifikasikan, percobaan ulang dapat dikendalikan, dan status perjalanan data mudah dipahami. Mekanisme antrean apa pun bukan penyimpanan tanpa batas atau jaminan bahwa sistem tujuan akan pulih.
Tambahkan jitter ketika banyak worker dapat retry pada waktu yang sama. Backoff tanpa jitter membuat seluruh pesan bangun bersamaan dan kembali membebani service yang baru pulih. Gunakan batas concurrency serta rate limit yang mengikuti kapasitas tujuan. Untuk antrian prioritas, jangan biarkan satu pesan bermasalah menghalangi seluruh kelompok bila urutan mutlak tidak diwajibkan bisnis.
Kebijakan perlu diuji sebagai kontrak, bukan hanya konfigurasi angka. Simulasikan timeout sebelum request sampai, timeout setelah tujuan memproses, respons 429 dengan Retry-After, serta error validation permanen. Pastikan dashboard menunjukkan attempt dan jadwal berikutnya, sementara alert tidak dibuat untuk setiap attempt transient. Alert sebaiknya menyorot tren, backlog, usia pesan, dan pesan yang mendekati retensi agar operator dapat bertindak sebelum kehilangan kesempatan pemrosesan.
Review kebijakan setelah melihat data produksi. Jika hampir seluruh retry untuk satu kode selalu gagal, klasifikasi mungkin salah. Jika percobaan kedua sering berhasil tetapi antrean tumbuh, backoff atau kapasitas perlu dievaluasi. Perubahan harus melalui Sandbox dan simulasi gangguan; menaikkan jumlah attempt tanpa analisis hanya memindahkan masalah menjadi beban yang lebih lama.
Batasan yang tidak boleh ditutupi retry
Transaksi ACID hanya pada satu koneksi database. API dan email eksternal bersifat at-least-once, sehingga idempotensi tujuan dan rekonsiliasi tetap diperlukan.
Rancang jalur gagal sebelum Production dan uji dengan Sandbox. Untuk memahami risiko pengulangan lebih lanjut, lanjutkan ke pemilihan operasi database dan alur agent-centric tempat antrean dan agent bekerja.