İdempotency’yi Akışın Temel Kuralı Yapın

n8n, Make, Zapier veya benzeri platformlarda aynı olay birden fazla kez alınabilir. Gönderen sistemin yeniden denemesi, ağ kopması ya da bir adımın zaman aşımına uğraması; aynı siparişin, form kaydının veya destek talebinin iki kez işlenmesine yol açabilir.

Akışın girişinde her olay için benzersiz bir idempotency key belirleyin. En güvenilir seçenek, gönderen sistemin olay kimliğini kullanmaktır. Böyle bir alan yoksa sipariş numarası ve olay türü gibi değişmeyen alanlardan kontrollü bir anahtar üretin. Yalnızca zaman damgasını anahtar yapmak güvenli değildir; aynı olayın farklı zamanlarda yeniden gönderilmesi çakışmayı önleyebilir.

Aynı anahtar tekrar geldiğinde yeni kayıt oluşturmak yerine önceki işlem durumunu okuyun. Durum tamamlandı ise önceki sonucu döndürün; bekliyor veya işleniyor ise ikinci paralel çalışmayı engelleyin. İdempotency kaydı en az şu bilgileri içermelidir:

• Olay anahtarı ve olay türü.
• İlk görülme zamanı ile son güncelleme zamanı.
• İşlem durumu: bekliyor, işleniyor, tamamlandı veya başarısız.
• Güvenli sonuç özeti ve correlation ID.

Platformun yerleşik veri saklama özelliği yetersiz veya geçici ise bu kayıtları güvenilir bir harici veri deposunda tutun. Anahtar kontrolü ile yan etki oluşturan adım arasında yarış koşulu oluşmaması için mümkünse atomik kayıt veya kilitleme mekanizması kullanın.

Webhook Girişini Doğrulayın, Ağır İşlemi Kuyruğa Alın

Webhook uç noktasını tüm iş mantığını çalıştıran geniş bir kapı olarak değil, doğrulayan ve olayı güvenli biçimde kaydeden ince bir giriş katmanı olarak tasarlayın.

• İmza, paylaşılan gizli değer veya sağlayıcının doğrulama mekanizmasını kontrol edin.
• HTTP yöntemi, içerik türü, zorunlu alanlar ve makul gövde boyutunu doğrulayın.
• Olay kimliğini kontrol etmeden e-posta gönderme, ödeme başlatma veya CRM güncelleme gibi yan etkilere geçmeyin.
• İsteği aldıktan sonra hızlı bir başarı yanıtı verin; ağır işlemleri kuyruk, bekleyen durum veya ayrı bir alt iş akışı üzerinden yürütün.
• Token, parola, imza ve kişisel verileri loglarda maskeleyin.

Aynı webhook olayının art arda gelmesi durumunda yalnızca bir çalışmanın ilerlediğini test edin. Gönderen servis hızlı yanıt bekliyorsa, uzun süren bir akışı doğrudan webhook isteğine bağlamak yerine kabul etme ve arka planda işleme modelini kullanın.

Hataları Yeniden Denenebilir ve Kalıcı Olarak Ayırın

Her hatayı otomatik olarak yeniden denemek güvenli değildir. Hataları operasyonel olarak iki sınıfa ayırın:

• Geçici hatalar: bağlantı kopması, zaman aşımı, geçici servis yoğunluğu ve uygun bir HTTP yanıtıyla bildirilen rate limit durumu.
• Kalıcı hatalar: eksik zorunlu alan, geçersiz kimlik, yetki problemi veya iş kuralı ihlali.

Geçici hatalarda sabit aralık yerine giderek artan bekleme, sınırlı deneme sayısı ve mümkünse rastgele küçük bir sapma kullanın. Rate limit yanıtında Retry-After benzeri bir süre veriliyorsa buna uyun; tüm istekleri aynı anda yeniden başlatmayın. E-posta, ödeme veya stok güncellemesi gibi yan etkili işlemlerde idempotency kontrolü olmadan retry uygulamayın.

Kalıcı hataları yeniden kuyruğa almak yerine hata akışına veya inceleme kuyruğuna yönlendirin. Hata kaydında olay anahtarı, başarısız adım, güvenli hata özeti, deneme sayısı ve önerilen sonraki işlem bulunmalı; ham gizli veri bulunmamalıdır.

Gözlemlenebilirlik, Gizlilik ve Bakım Kolaylığı

Her çalışmaya bir correlation ID verin ve bunu alt iş akışlarına taşıyın. En az şu sinyalleri izleyin:

• Başarılı, bekleyen ve başarısız çalışma sayıları.
• Adım bazında işlem süresi ve yeniden deneme sayısı.
• Hata kuyruğundaki olayların yaşı.
• Rate limit nedeniyle ertelenen istekler.
• İdempotency çakışması ve yinelenen olay oranı.

Kimlik bilgilerini akış metnine sabitlemeyin; n8n credential alanlarını, Make bağlantılarını veya Zapier’in güvenli kimlik bilgisi özelliklerini kullanın. Gereksiz kişisel veriyi adımlar arasında taşımayın, saklama süresini belirleyin ve testlerde gerçek müşteri kayıtlarını kullanmayın. Büyük akışı doğrulama, dönüştürme, dış servise gönderme ve hata işleme gibi küçük alt akışlara bölmek; sağlayıcı değişikliklerini ve bakım testlerini kolaylaştırır.

Yayın Öncesi ve Yeniden Oynatma Kontrolü

Canlıya almadan önce aynı webhook olayını art arda gönderin, yanıt gecikmesini simüle edin ve dış servisin rate limit davranışını test edin. Şu soruların ölçülebilir yanıtı olmalıdır: Aynı olay iki kez gelirse kaç kayıt oluşur? Bir adım başarısız olduğunda sonraki adım yanlışlıkla çalışır mı? Hata kaydından güvenli yeniden oynatma yapılabilir mi? Loglarda gizli bilgi görünür mü? Sağlayıcının alan adı veya API sürümü değişirse hangi adım etkilenir?

Yeniden oynatma özelliğini sınırsız bırakmayın. Yetkili kullanıcı, olay kimliği, deneme sınırı ve kontrollü durum geçişiyle sınırlandırın. Böylece otomasyon yalnızca hızlı kurulmuş değil; tekrar edilebilir, denetlenebilir ve uzun süre bakımı yapılabilir hale gelir.