Webhook Masuk Dua Kali? Cara Membuat Workflow n8n Aman dari Data Ganda

Webhook terlihat sederhana: sebuah layanan mengirim data, lalu n8n menjalankan workflow. Masalahnya, pengiriman data tidak selalu terjadi satu kali. Layanan pengirim bisa mengulang request ketika respons terlambat, koneksi terputus, atau server menganggap request sebelumnya gagal.

Akibatnya, satu pesanan dapat masuk dua kali, satu pelanggan menerima dua pesan WhatsApp, atau satu tiket dukungan dibuat berulang. Di sinilah idempotensi menjadi penting. Sederhananya, idempotensi berarti menjalankan event yang sama beberapa kali tetap menghasilkan efek akhir yang sama seperti menjalankannya satu kali.

Kenapa webhook bisa menghasilkan data ganda?

Banyak orang menganggap duplikasi hanya terjadi karena workflow n8n salah. Padahal, sumber masalahnya bisa berada di antara beberapa sistem.

• Pengirim mengulang request karena tidak menerima respons tepat waktu.
• Pengguna menekan tombol checkout lebih dari sekali.
• Workflow gagal setelah data berhasil disimpan, tetapi sebelum respons selesai dikirim.
• Operator menjalankan ulang execution yang gagal.
• Satu event dikirim melalui lebih dari satu jalur integrasi.

n8n menyediakan daftar execution dan opsi untuk menjalankan ulang workflow yang gagal. Fitur ini membantu pemulihan, tetapi juga berarti workflow perlu dirancang agar aman ketika data lama diproses kembali. Dokumentasi resmi n8n menjelaskan bahwa execution yang gagal dapat diulang menggunakan workflow yang sedang tersimpan atau versi asli saat execution berlangsung.

Gunakan event ID sebagai nomor tiket

Cara paling praktis untuk mencegah duplikasi adalah meminta atau membuat event ID. Nilai ini menjadi nomor unik untuk setiap event, mirip nomor tiket pada layanan pelanggan.

Misalnya, payload webhook dari sistem pembayaran memiliki data berikut:

{
  "event_id": "evt_20260927_00123",
  "type": "payment.success",
  "order_id": "ORD-8821",
  "amount": 250000
}

Workflow tidak cukup hanya memeriksa apakah order_id sudah ada. Satu pesanan kadang memiliki beberapa event yang sah, seperti pembayaran dibuat, pembayaran berhasil, lalu pembayaran dikembalikan. Untuk membedakan setiap kejadian, gunakan ID event dari pengirim jika tersedia.

Jika pengirim tidak menyediakan ID unik, buat kunci berdasarkan kombinasi data yang stabil, misalnya nama_layanan + order_id + tipe_event. Hindari menggunakan waktu eksekusi sebagai satu-satunya pembeda karena request yang sama dapat diproses pada waktu berbeda.

Rancangan workflow n8n yang lebih aman

Struktur dasarnya dapat dibuat seperti ini:

1. Webhook: menerima payload dari layanan pengirim.
2. Set atau Code: mengambil dan menormalkan event ID.
3. Database: mencari apakah event ID tersebut pernah diproses.
4. IF: menghentikan workflow jika event sudah tercatat.
5. Proses utama: membuat invoice, mengirim notifikasi, atau memperbarui CRM.
6. Database: menyimpan event ID setelah proses berhasil.

Logika sederhananya dapat dibaca seperti ini: “Jika event belum pernah diproses, jalankan pekerjaan. Jika sudah pernah diproses, jangan ulangi efeknya.”

Untuk workflow penting, jangan hanya menyimpan status di memori node atau mengandalkan riwayat execution. Gunakan penyimpanan yang memang dirancang untuk dibaca kembali, seperti tabel database, Redis, atau penyimpanan terpusat lain yang digunakan tim Anda.

Urutan penyimpanan menentukan hasil

Ada dua pilihan umum untuk mencatat event: sebelum proses utama atau sesudah proses utama. Keduanya memiliki risiko.

Jika event dicatat sebelum proses utama, workflow memang lebih tahan terhadap request ganda. Namun, jika proses utama gagal setelah pencatatan, pengulangan berikutnya bisa dianggap duplikat dan pekerjaan tidak pernah selesai.

Jika event dicatat sesudah proses utama, kegagalan di tengah proses dapat membuat event diproses ulang. Ini aman hanya jika aksi utama juga idempotent. Contohnya, operasi “perbarui status pesanan menjadi paid” biasanya lebih aman diulang daripada operasi “buat pesanan baru”.

Untuk proses yang berdampak besar, gunakan transaksi database atau mekanisme kunci unik. Kolom event_id dapat diberi aturan unique, sehingga dua execution yang datang hampir bersamaan tidak dapat membuat catatan yang sama.

Bedakan deduplikasi batch dan deduplikasi event

n8n memiliki node dan pola kerja yang dapat membantu menghapus item duplikat dalam satu aliran data. Itu berguna ketika satu execution membawa daftar yang berisi baris sama, misalnya hasil pembacaan spreadsheet atau RSS.

Namun, deduplikasi dalam satu batch berbeda dengan mencegah event yang sama masuk pada dua execution terpisah. Jika webhook yang sama diterima pada pukul 10.00 dan 10.02, workflow perlu memeriksa penyimpanan bersama, bukan hanya membandingkan item yang sedang berada di execution saat ini.

Ini perbedaan kecil yang sering terlewat: duplikat di dalam data tidak sama dengan duplikat di dalam waktu.

Jangan lupakan efek samping

Beberapa langkah terlihat tidak berbahaya, tetapi sebenarnya memiliki efek samping yang sulit dibatalkan:

• Mengirim email atau pesan WhatsApp.
• Membuat invoice baru.
• Mengurangi stok.
• Menambah saldo atau poin pelanggan.
• Membuat kartu baru di project management.
• Mengirim data ke sistem analitik tanpa ID unik.

Untuk setiap langkah, tanyakan: “Jika node ini dijalankan dua kali, apa yang terjadi?” Jika jawabannya adalah “data bertambah dua kali”, cari operasi alternatif seperti upsert—memperbarui data jika sudah ada dan membuat data baru jika belum ada.

Tambahkan jalur audit dan pemulihan

Workflow yang aman bukan workflow yang tidak pernah gagal. Workflow yang baik adalah workflow yang kegagalannya mudah dilihat dan dipulihkan.

Simpan setidaknya event ID, waktu diterima, tipe event, status pemrosesan, dan pesan error. Gunakan nama workflow yang jelas agar execution mudah dicari. n8n juga menyediakan fitur audit untuk membantu menemukan sejumlah risiko pada instance, termasuk webhook yang tidak terlindungi dan konfigurasi keamanan yang bermasalah. Detailnya tersedia di dokumentasi security audit n8n.

Jika proses utama gagal, jangan langsung mengirim ulang event secara manual tanpa memahami titik gagalnya. Periksa apakah data sudah sempat dibuat. Kalau sudah, jalankan langkah pembaruan atau gunakan jalur pemulihan khusus, bukan mengulang seluruh workflow dari awal.

Yang bisa dilakukan sekarang

1. Periksa semua webhook yang membuat data baru atau mengirim pesan.
2. Pastikan setiap event memiliki ID unik dan stabil.
3. Buat tabel log pemrosesan dengan kolom event ID dan status.
4. Tambahkan pemeriksaan duplikat sebelum efek samping dijalankan.
5. Gunakan aturan unique di database jika memungkinkan.
6. Uji request yang sama sebanyak dua atau tiga kali.
7. Simulasikan kegagalan setelah data tersimpan tetapi sebelum workflow selesai.

Idempotensi bukan fitur tambahan yang hanya dibutuhkan perusahaan besar. Begitu workflow mulai menangani pembayaran, leads, pesanan, atau notifikasi pelanggan, perlindungan terhadap data ganda menjadi bagian dari kualitas dasar sistem.

n8n memudahkan kita menghubungkan banyak layanan. Tetapi semakin banyak koneksi yang dibuat, semakin penting setiap event memiliki identitas, status, dan jalur pemulihan yang jelas. Otomatisasi yang baik bukan sekadar berjalan saat semuanya normal, melainkan tetap masuk akal ketika jaringan lambat, request diulang, atau workflow harus dipulihkan.

Sumber & bacaan lebih lanjut

• n8n Docs: All executions and retry failed workflows
• n8n Docs: Security audit

– Rio Yotto @rioyotto