Digital Transformation

Webhook Retry

Vito Atmo
Vito Atmo·8 Juni 2026·1 kali dibaca·2 min baca

TL;DR: Webhook retry adalah mekanisme di mana sistem pengirim mengirim ulang sebuah webhook secara otomatis ketika penerima tidak merespons dengan benar, misalnya karena server sedang down atau timeout. Tujuannya menjaga agar event penting, seperti notifikasi pembayaran, tetap sampai meski ada gangguan sesaat. Retry biasanya memakai jeda yang membesar bertahap (exponential backoff).

Apa itu Webhook Retry?

Webhook retry adalah strategi keandalan pada arsitektur webhook. Saat sebuah event terjadi, sistem pengirim mengetuk URL penerima. Jika penerima membalas dengan status sukses, selesai. Jika gagal atau diam, sistem pengirim menjadwalkan pengiriman ulang sesuai aturan retry.

Analoginya seperti kurir yang datang lagi keesokan hari saat rumah kosong, bukan langsung membuang paket. Tanpa retry, satu gangguan singkat di sisi penerima bisa membuat data event hilang permanen.

Pola Retry yang Umum

  • Exponential backoff: jeda antar percobaan membesar, misalnya 1, 2, 4, 8 menit, agar tidak membanjiri penerima yang sedang pulih.
  • Batas maksimum percobaan: retry berhenti setelah sejumlah kali, lalu event ditandai gagal.
  • Idempotency key: penanda unik agar penerima bisa mengenali dan mengabaikan event ganda dari retry.

Tanpa idempotency, retry berisiko memproses transaksi yang sama dua kali. Konsep ini berkaitan erat dengan pembatasan beban seperti rate limiting.

Kenapa Penting?

Untuk integrasi yang memicu uang atau status pesanan, kehilangan satu event bisa berakibat serius, seperti pembayaran masuk tapi pesanan tidak terbarui. Saat membangun integrasi pembayaran untuk proyek, menangani retry beserta idempotency menjadi pembeda antara sistem yang tahan gangguan dan yang rapuh terhadap timeout sesaat. Praktik baik desain webhook dibahas di dokumentasi webhook Stripe.

Pertanyaan Umum

Berapa lama sistem biasanya mencoba ulang?

Bervariasi per platform, umumnya beberapa jam hingga beberapa hari dengan jeda yang membesar, sebelum akhirnya menyerah.

Bagaimana mencegah data diproses dua kali akibat retry?

Gunakan idempotency key. Penerima menyimpan ID event yang sudah diproses dan mengabaikan duplikatnya.

Bagikan