ERP entegrasyonları kırılgan olduğunda sorun çoğu zaman ilk hatada değil, ikinci denemede başlar. Ağ kesintisi, uzak sistem timeout’u veya sıra birikmesi nedeniyle tekrar edilen çağrılar; siparişin iki kez açılmasına, faturanın tekrarlı oluşmasına veya stok mutabakatının bozulmasına yol açabilir. Bu yüzden retry mekanizması yalnızca dayanıklılık değil, veri doğruluğu mimarisidir.
Neden klasik retry mantığı ERP dünyasında yetmez?
Birçok uygulama retry’i basitçe “başarısız olduysa yeniden dene” olarak uygular. Fakat ERP sistemleri genellikle durum tutan, yan etki üreten ve işlem geçmişini sıkı denetleyen ortamlardır. Çağrı hedefe ulaşıp yanıt dönmediyse, istemci başarısızlık görürken arka tarafta kayıt çoktan oluşmuş olabilir.
Bu nedenle retry kararı, sadece ağ hatasına verilen tepki değil; işlemin iş anahtarı, yan etki tipi ve uzlaştırma yeteneğiyle birlikte ele alınmalıdır.
Retry koridoru neyi ifade eder?
Ben retry koridorunu, tekrar denemelerin rastgele uygulama kodunda değil ortak bir güvenlik alanında yürütülmesi olarak düşünüyorum. Bu koridor tipik olarak şu sorumlulukları taşır:
- İdempotency key üretimi ve saklanması
- İlk denemenin durumunu izleme
- Gecikmeli yeniden deneme politikası
- Zehirli mesaj ayrıştırması
- Manuel uzlaştırma kuyruğu
Bu yapı sayesinde aynı entegrasyon davranışı farklı ekiplerde farklı biçimde yeniden yazılmaz. Kurumsal mimaride standartlaşma tam burada değer üretir.
İdempotency key nasıl seçilmeli?
En sık hata, idempotency key’i teknik istek kimliğiyle sınırlamaktır. Daha doğru yaklaşım iş anlamını taşıyan birleşik anahtarlar kullanmaktır. Örneğin:
- Sipariş numarası + işlem tipi
- Fatura numarası + versiyon
- Kaynak sistem olay kimliği + hedef kayıt türü
Bu sayede ağ yeniden denemesi ile gerçekten yeni bir iş olayı birbirinden ayrılır. Aksi hâlde sistem teknik olarak dayanıklı görünür ama iş verisi sessizce bozulur.
Gözlemlenebilirlik neden tasarımın merkezinde?
Retry davranışı görünmüyorsa güven vermez. Koridorun şu sinyalleri üretmesi gerekir:
- Bekleyen retry sayısı
- Maksimum deneme eşiğine takılan kayıtlar
- İşlem türüne göre tekrar oranı
- Uzlaştırma kuyruğuna düşen iş yüzdesi
Bu metrikler sadece operasyon ekibine değil, entegrasyon mimarisinin sağlığına da ayna tutar. Özellikle ay sonu ERP yoğunluklarında hangi bağlantıların sistematik olarak kırıldığını bu yüzeyden okuyabilirsiniz.
Hangi durumlarda otomatik retry yapılmamalı?
Her hata geçici değildir. Aşağıdaki durumlar genellikle otomatik tekrar için kötü adaydır:
- Şema veya zorunlu alan hatası
- Yetki ve sertifika problemi
- İş kuralı ihlali
- Sürüm uyumsuzluğu
Bu tip durumlarda agresif retry yalnızca kuyruk doldurur ve gerçek problemi gizler. Koridorun asıl olgunluğu, tekrar etmek kadar durmayı da bilmesidir.
Kurumsal uygulama modeli
Pratikte şu katmanlı model işe yarar:
- API veya mesaj girişinde idempotency key doğrulaması
- Durum deposunda ilk denemenin kaydı
- Retry scheduler ile gecikmeli deneme
- Dead-letter veya uzlaştırma kuyruğu
- Dashboard ve incident alarm yüzeyi
Bu akış, ERP entegrasyonlarını sadece “çalışıyor mu” seviyesinden “tekrar bozulduğunda da kontrollü mü” seviyesine çıkarır.
Sonuç
ERP entegrasyonlarında idempotent retry koridoru, dayanıklılık ile veri bütünlüğünü aynı tasarımda buluşturur. Tekrar denemeyi uygulama içindeki dağınık reflekslerden çıkarıp ortak mimari yüzeye taşıdığınızda; hatalar daha az gizlenir, operasyon daha hızlı toparlanır ve kurumsal veri güveni belirgin biçimde artar.