Webhook adalah cara paling umum menghubungkan sistem mutasi rekening dengan sistem internal: begitu ada transaksi baru, notifikasi dikirim langsung ke server Anda tanpa perlu menanyakannya berulang-ulang. Tapi ada satu pertanyaan yang jarang dipikirkan sampai benar-benar terjadi: bagaimana jika server penerima webhook sedang down, atau koneksinya timeout, tepat pada saat notifikasi dikirim?
Jawaban atas pertanyaan ini menentukan apakah sistem webhook Anda benar-benar bisa diandalkan, atau hanya terlihat bekerja selama tidak ada gangguan.
Risiko webhook tanpa mekanisme retry
Dalam implementasi webhook yang paling sederhana, pengirim hanya mencoba mengirim notifikasi satu kali. Jika percobaan itu gagal — karena server penerima sedang restart deploy, jaringan timeout, atau sekadar lambat merespons — notifikasi itu hilang begitu saja. Tidak ada percobaan kedua, dan pengirim tidak punya cara untuk tahu apakah penerima benar-benar menerima data tersebut atau tidak.
Untuk data mutasi rekening, risiko ini tidak bisa dianggap sepele. Satu webhook yang gagal terkirim berarti satu transaksi yang tidak tercatat di sistem internal — yang bisa berarti invoice yang tidak otomatis ditandai lunas, atau pesanan yang tertahan karena sistem mengira pembayaran belum masuk, padahal dananya sudah ada di rekening.
Antrian dan retry sebagai solusi
Pendekatan yang lebih andal adalah memperlakukan setiap pengiriman webhook yang gagal bukan sebagai kegagalan permanen, melainkan sebagai sesuatu yang perlu dicoba lagi. Secara konsep, ini bekerja dengan menempatkan notifikasi yang gagal terkirim ke dalam sebuah antrian (queue), lalu mencobanya kembali setelah jeda waktu tertentu. Jika percobaan berikutnya juga gagal, notifikasi tetap berada di antrian untuk dicoba lagi, alih-alih langsung dibuang.
Mutasiku menerapkan prinsip ini pada pengiriman webhook: pengiriman yang gagal — misalnya karena endpoint tujuan tidak merespons atau sedang tidak bisa dijangkau — tidak langsung dianggap selesai dan dihapus, melainkan masuk ke antrian dan dicoba kembali secara otomatis. Dengan begitu, gangguan sesaat di server penerima — yang dalam praktiknya cukup umum terjadi, misalnya saat proses deploy ulang — tidak otomatis berarti data mutasi itu hilang dari sisi penerima.
Retry otomatis bukan jaminan mutlak bahwa data tidak akan pernah hilang — jika endpoint penerima memang tidak pernah kembali aktif dalam jangka waktu yang wajar, percobaan retry pada akhirnya akan berhenti. Karena itu, log aktivitas tetap penting sebagai jaring pengaman kedua: Anda bisa melihat riwayat pengiriman webhook dan mendeteksi pola kegagalan sebelum menjadi masalah besar.
Bagaimana retry yang baik biasanya dirancang
Secara umum, ada beberapa prinsip rekayasa yang dipakai sistem pengiriman webhook yang andal, terlepas dari detail implementasi spesifik masing-masing penyedia. Memahami prinsip-prinsip ini membantu Anda menilai apakah mekanisme retry yang ditawarkan penyedia mana pun memang dirancang dengan matang, bukan sekadar klaim “ada retry” tanpa kejelasan lebih lanjut.
Pertama, jeda antar percobaan biasanya tidak konstan, melainkan membesar secara bertahap — pendekatan yang sering disebut backoff. Logikanya sederhana: jika percobaan pertama gagal karena server penerima sedang restart sebentar, percobaan kedua yang dilakukan tak lama setelahnya punya peluang besar berhasil. Tapi jika beberapa percobaan berturut-turut tetap gagal, kemungkinan besar masalahnya lebih serius (misalnya endpoint memang sedang down lama), sehingga jeda yang semakin panjang antar percobaan berikutnya masuk akal — ini juga menghindari membanjiri endpoint yang sedang bermasalah dengan percobaan yang terlalu rapat.
Kedua, retry punya jangka waktu yang wajar, bukan berlangsung selamanya. Sebuah notifikasi yang terus gagal selama berhari-hari biasanya menandakan masalah struktural pada sisi penerima — endpoint yang sudah tidak aktif, URL yang berubah, atau konfigurasi yang salah — yang tidak akan terselesaikan hanya dengan mencoba lebih banyak kali. Pada titik ini, sistem yang baik akan berhenti mencoba dan mengandalkan log aktivitas untuk memberi tahu bahwa ada pengiriman yang akhirnya tidak berhasil, sehingga masalahnya bisa ditangani secara manual.
Ketiga, setiap percobaan — berhasil maupun gagal — idealnya tercatat, bukan hanya percobaan terakhir. Riwayat lengkap ini yang memungkinkan Anda, atau tim dukungan teknis penyedia, menelusuri pola: apakah kegagalan terjadi hanya sesekali (tanda gangguan sesaat yang wajar), atau berulang pada jam tertentu (tanda ada masalah kapasitas di sisi penerima yang perlu diselidiki lebih lanjut).
Kenapa audit log tetap penting di samping retry
Retry menjawab pertanyaan “bagaimana supaya notifikasi akhirnya sampai”. Tapi ada pertanyaan lain yang sama pentingnya dan tidak dijawab oleh retry saja: “bagaimana saya tahu notifikasi itu akhirnya benar-benar sampai, dan kapan?” Di sinilah audit log atau riwayat pengiriman webhook berperan sebagai pelengkap, bukan sekadar fitur tambahan.
Tanpa riwayat yang bisa ditelusuri, tim Anda tidak punya cara memverifikasi apakah satu transaksi yang tampaknya belum tercatat di sistem internal memang belum terkirim, sedang dalam proses retry, atau sudah terkirim tapi gagal diproses di sisi penerima karena alasan lain. Ketiga kemungkinan ini membutuhkan tindakan yang berbeda, dan tanpa log yang jelas, tim hanya bisa menebak-nebak sambil menunggu dan berharap.
Riwayat pengiriman yang baik idealnya mencatat kapan setiap percobaan dilakukan, status responsnya, dan apakah transaksi tersebut akhirnya berhasil diteruskan. Dengan data ini, tim teknis bisa memverifikasi secara pasti bahwa satu transaksi tertentu sudah terkirim meski sempat gagal di percobaan pertama — daripada harus menebak berdasarkan asumsi bahwa “biasanya webhook jalan dengan baik”. Untuk bisnis yang mengandalkan data mutasi demi memutuskan hal-hal operasional (mengirim barang, mengaktifkan layanan), kepastian seperti ini jauh lebih bernilai dibanding sekadar kepercayaan bahwa sistem berjalan normal.
Kenapa ini penting dari sudut pandang bisnis, bukan hanya teknis
Mudah untuk menganggap retry dan antrian sebagai detail implementasi yang hanya relevan bagi developer. Tapi dari sudut pandang bisnis, ini berarti satu hal yang konkret: keandalan integrasi Anda tidak bergantung sepenuhnya pada seberapa stabil server internal Anda setiap saat. Server bisa down sesaat untuk pemeliharaan, mengalami lonjakan trafik, atau gagal merespons karena alasan di luar kendali tim — dan sistem webhook yang dirancang dengan retry tetap memastikan data sampai begitu server kembali normal.
Ini juga mengurangi tekanan pada tim teknis untuk menjaga uptime server penerima webhook mendekati sempurna sepanjang waktu, karena ada toleransi bawaan terhadap gangguan sesaat.
Webhook tanpa retry
Webhook dengan antrian dan retry
Yang perlu diperhatikan tim developer penerima webhook
Mekanisme retry di sisi pengirim hanya efektif jika sisi penerima juga dirancang dengan benar. Beberapa hal yang perlu diperhatikan tim yang membangun endpoint penerima webhook:
| Aspek | Kenapa penting |
|---|---|
| Idempotensi pemrosesan | Karena retry berarti notifikasi yang sama bisa diterima lebih dari sekali, endpoint perlu mampu menangani duplikasi tanpa mencatat transaksi dua kali. |
| Respons cepat dengan status sukses | Endpoint sebaiknya segera merespons setelah data diterima, lalu memproses data secara terpisah, agar tidak dianggap gagal karena lambat merespons. |
| Pemantauan log pengiriman | Memantau riwayat pengiriman webhook membantu mendeteksi pola kegagalan berulang sebelum menjadi masalah besar. |
Webhook yang andal bukan soal mengirim notifikasi secepat mungkin dalam kondisi ideal, melainkan soal memastikan data tetap sampai meskipun kondisi tidak ideal. Antrian dan retry adalah cara paling mendasar untuk mencapai itu, dan menjadi bagian penting dari integrasi mutasi rekening yang bisa benar-benar diandalkan oleh sistem internal Anda.