Entegrasyonda mükerrer kayıt neden oluşur, nasıl önlenir

Aynı siparişin ya da aynı faturanın sisteme iki kez düşmesinin sebebi çoğu zaman kullanıcı hatası değil, entegrasyonun yeniden deneme davranışıdır. Bir istek karşı tarafa ulaştı mı ulaşmadı mı belirsiz kaldığında gönderen taraf isteği tekrarlar; alıcı taraf bu tekrarı yeni bir kayıt sayarsa mükerrer kayıt doğar. Doğru yaklaşım tekrarı yasaklamaya çalışmak değil, tekrarın sonucu değiştirmemesini sağlamaktır. Aşağıda kopya kayıtların nereden geldiğini, hangi önlemin hangi katmanda alındığını ve oluşmuş kopyaların nasıl temizlendiğini anlatıyoruz.

Kopya kayıt tam olarak nerede doğar

İki sistem arasındaki hat kusursuz değildir. İstek gider, karşı taraf kaydı yazar, ama cevap dönerken bağlantı kopar ya da zaman aşımına uğrar. Gönderen taraf için sonuç başarısız görünür ve istek tekrarlanır. Alıcı tarafta ise artık iki kayıt vardır ve ikisi de geçerli görünür. Kimse yanlış bir şey yapmamıştır; sistem tasarımı tekrarı hesaba katmamıştır.

Buradaki kritik ayrım şudur: ağ üzerinden tam bir kez teslim pratikte garanti edilemez. Kuyruk sistemleri dahil yaygın çözümlerin verdiği güvence en az bir kez teslimidir. Yani tekrar anormal değil, beklenen bir durumdur ve yazılımın tekrarı tanıyıp yutması gerekir. Entegrasyonun genel çerçevesini API, webhook ve kuyruk yazısında ele almıştık; burada tek bir arıza biçimine odaklanıyoruz.

En sık görülen beş kaynak

• Zaman aşımı sonrası tekrar: İşlem karşı tarafta tamamlanır, cevap gecikir, gönderen servis aynı veriyi ikinci kez yollar.
• Webhook yeniden gönderimi: Bildirimi alan uç zamanında başarı cevabı dönmezse gönderen sistem aynı bildirimi tekrar iletir. Bu hatalı değil, tasarlanmış bir davranıştır.
• Toplu aktarımın baştan çalıştırılması: Gece işi yarıda kalır, sabah elle yeniden başlatılır ve ilk turda işlenmiş kayıtlar ikinci kez yazılır.
• Arayüzde çift tıklama: Yavaş yanıt veren bir forma kullanıcı iki kez basar; iki istek de sunucuya ulaşır ve ikisi de işlenir.
• Paralel çalışan iki işçi: Kuyruğu dinleyen iki süreç aynı mesajı yaklaşık aynı anda alır; ikisi de bu kayıt yok kontrolünü geçer ve ikisi de yazar.

İdempotency anahtarı ne işe yarar

İdempotency, aynı işlemin bir kez de on kez de çalıştırılsa sonucun aynı kalması demektir. Pratikte bunu sağlayan şey, her isteğe iş anlamı taşıyan ve tekrar üretilebilen bir anahtar iliştirmektir. Bu anahtar çoğu zaman kaynak sistemdeki belge numarasıdır: pazaryerinin sipariş numarası, muhasebe tarafındaki fiş numarası, kargo firmasının gönderi kimliği.

Alıcı taraf isteği işlerken önce bu anahtarı kontrol eder. Anahtar daha önce işlenmişse yeni kayıt açmaz; ilk işlemin sonucunu aynen döndürür. Gönderen taraf beklediği cevabı aldığı için yeniden denemeyi bırakır ve zincir orada kapanır. Her denemede değişen rastgele bir anahtar bu işi görmez; anahtarın tekrar denemelerinde de aynı kalması şarttır.

Hangi önlem hangi katmanda alınır

Bu katmanlar birbirinin yedeğidir. Yalnızca arayüzde önlem almak yetmez, çünkü istek arayüzden değil entegrasyondan da gelir. Yalnızca uygulama içinde önce bak sonra yaz kontrolü yapmak da yetmez, çünkü iki paralel süreç aynı kontrolü aynı anda geçebilir. Son sözü söyleyen katman veritabanındaki benzersizlik kuralıdır.

Yeniden deneme politikası nasıl kurulur

1. Geçici ve kalıcı hatayı ayırın. Bağlantı kopması geçicidir, tekrar denenir. Geçersiz vergi numarası kalıcıdır; yüz kez denemek sonucu değiştirmez, yalnızca kuyruğu tıkar.
2. Kademeli bekleme uygulayın. Denemeler arasındaki süre artarak gitsin; saniyede onlarca tekrar hem karşı tarafı hem kendi sisteminizi kilitler.
3. Deneme sayısını sınırlayın. Belirli sayıdan sonra mesaj ölü mektup kuyruğuna alınsın ve insan müdahalesi beklesin.
4. Her denemeyi kaydedin. Anahtar, zaman damgası, dönen hata kodu ve cevap gövdesi kayıtta yoksa teşhis tahmine dönüşür.
5. Sessiz başarısızlığa izin vermeyin. Ölü mektup kuyruğuna düşen her kayıt bir uyarı üretmeli; kimsenin bakmadığı kuyruk gecikmiş veri kaybıdır.

Oluşmuş kopyalar nasıl temizlenir

Kopya kayıt bulunduğunda ilk iş silmek değil, hangisinin doğru olduğunu belirlemektir. Kayıtlardan biri muhasebeye aktarılmış, diğerine kargo etiketi basılmış olabilir; yanlış olanı silerseniz bağlı hareketler sahipsiz kalır. Temizlik sırası şöyle işler: önce kopya kümeleri raporlanır, her küme için bir ana kayıt seçilir, bağlı hareketler ana kayda taşınır, fazla kayıt silinmek yerine iptal durumuna alınır ve iz kaydına gerekçe yazılır. Silmek yerine iptal etmek, sonradan gelen bir mutabakat sorusunda geçmişi görebilmenizi sağlar.

Temizlikten sonra benzersizlik kuralı konulmazsa aynı sorun birkaç hafta içinde geri gelir. Kuralı koymadan önce mevcut veride çakışma olup olmadığı kontrol edilir; aksi hâlde kural eklenemez ve geçiş yarıda kalır. Bu yüzden temizlik ile kural koyma aynı çalışmanın iki adımı olarak planlanır.

Kısa kontrol listesi

• Her dış kaynaklı kayıtta, kaynak sistemin kendi belge numarası saklanıyor mu?
• Bu numara üzerinde veritabanı seviyesinde benzersizlik kuralı tanımlı mı?
• Webhook uçları aynı bildirimi ikinci kez aldığında hata değil, zaten işlendi cevabı veriyor mu?
• Toplu işler yarıda kalıp yeniden başlatıldığında işlenmiş kayıtları atlıyor mu?
• Ölü mektup kuyruğunu izleyen ve uyarı üreten bir mekanizma var mı?
• Kopya adayı raporu periyodik olarak birine düşüyor mu?

KAV Yazılım, özel yazılım ve entegrasyon projelerinde bu kontrolleri tasarım aşamasında kurar; sonradan eklenen tekillik kuralı her zaman daha zahmetli olur.