“Basit bir webhook bağlarız” cümlesi, üretim ortamında çoğu zaman yeniden deneme politikası, imza doğrulama, zaman aşımı ve ölü harf kuyruğu ile tamamlanmadan güvenilir olmaz. Otomasyon hatları büyüdükçe, görünmez hatalar müşteri deneyimine veya finansal kayıtlara yansır. Bu yazıda dayanıklılığı artıran başlıkları özetliyoruz.
En az bir kez teslim ve idempotency
Ağ kesintileri ve geç cevaplar yüzünden aynı olay iki kez gelebilir. Tüketici tarafında “aynı sipariş numarası ikinci kez gelirse ne olacak?” sorusunun cevabı kodda olmalıdır. Idempotent anahtarlar (sipariş ID, fatura UUID vb.) ve veritabanı kısıtları, çift işlem riskini azaltır.
Kuyruk: geri baskı ve tüketici hızı
Webhook’u doğrudan ağır işleme bağlamak, ani trafikte sistemi kilitleyebilir. Olayı kuyruğa alıp asenkron işlemek, tüketicinin sabit hızda ilerlemesini sağlar. Burada kritik nokta: kuyruk taşarsa ne olacak? DLQ (dead-letter queue) ve alarm eşikleri tanımlanmalıdır.
Gözlemlenebilirlik: log değil, iz
Her isteğe korelasyon kimliği (correlation id) eklemek, destek ve geliştirme ekiplerinin aynı hikâyeyi takip etmesini sağlar. Metriklerde başarısızlık oranı, gecikme yüzdelikleri ve yeniden deneme sayıları pano haline getirildiğinde, sorunlar kullanıcı şikâyetinden önce görülür.
Güvenlik ve imza
Webhook uçlarını herkese açık bırakmak yerine paylaşılan sır veya asimetrik imza ile doğrulama, replay saldırılarını zorlaştırır. IP allowlist tek başına yetmez; çünkü bulut çıkış IP’leri değişebilir.
Operasyon paneli
Entegrasyon yöneticilerinin “son 100 olayı” görebildiği hafif bir panel, mühendislik yükünü düşürür: yeniden tetikleme, durdurma, manuel onay gibi işlemler güvenli rol ile yapılabilir.
Özet
Dayanıklı otomasyon, özellik sayısından çok davranış sözleşmesi ile ölçülür: hata olunca ne olur, tekrar olunca ne olur, iz sürerken ne görürüz? Gani Yazılım’da entegrasyon projelerinde bu sözleşmeyi tasarımın parçası yapıyoruz. Benzer bir hat kurmayı planlıyorsanız iletişim üzerinden projenizi anlatın.