Webhook yeniden denemeleri vs manuel tekrar oynatma: daha güvenli kurtarma tasarımı

Bir webhook başarısız olduğunda ne bozulur

Bir webhook hatası nadiren sadece "teknik bir aksaklık" olarak kalır. Kullanıcıya göre uygulamanız bir şeyi unutmuş gibidir: bir sipariş "beklemede" kalır, bir abonelik açılmaz, bir bilet asla "ödenmiş" konumuna geçmez ya da teslimat durumu yanlış olur.

Çoğu insan webhook'u hiç görmez. Sadece ürününüz ile banka, e-posta kutusu veya panelin uyuşmadığını görürler. İş para içeriyorsa, bu fark güveni çabucak yok eder.

Hatalar genellikle sıkıcı nedenlerden kaynaklanır. Uç noktanız yavaştır ve zaman aşımına uğrar. Sunucunuz dağıtım sırasında 500 döner. Bir ağ hop'u isteği düşürür. Bazen iş tamamlanmış olsa da çok geç cevap verirsiniz. Sağlayıcıya bunların hepsi "teslim edilmedi" gibi görünür; bu yüzden yeniden dener veya olayı başarısız olarak işaretler.

Kurtarma tasarımı önemlidir çünkü webhook olayları genellikle geri alınamaz eylemleri temsil eder: bir ödemenin tamamlanması, bir iadenin verilmesi, hesap oluşturma, şifre sıfırlama veya gönderim yapılması gibi. Bir olayı kaçırırsanız veriniz yanlış olur. İki kez işlerseniz çift ücretlendirme veya çift kayıt oluşturma riski doğar.

Bu yüzden webhook yeniden denemeleri ve manuel tekrar oynatma bir mühendislik kararı olmaktan çok ürün kararına dönüşür. İki yol vardır:

• Sağlayıcı otomatik yeniden denemeleri: gönderen, başarı yanıtı alana kadar zaman çizelgesine göre tekrar dener.
• Sizin manuel tekrar oynatmanız: bir insan (destek veya yönetici kullanıcı) bir şey ters görünce yeniden işlemeyi tetikler.

Kullanıcılar sürpriz olmadan güvenilirlik bekler. Sistemin çoğu durumda kendi kendine toparlanması gerekir; insan devreye girdiğinde ise araçlar neler olacağını net göstermeli ve iki kere tıklansa bile güvenli olmalıdır. No-code bir yapı olsa bile her webhook'u "tekrar gelebilir" olarak ele alın.

Otomatik yeniden denemeler: nerede yardımcı olur, nerede zarar verir

Otomatik yeniden denemeler webhook'lar için varsayılan güvenlik ağıdır. Çoğu sağlayıcı ağ hatalarında ve zaman aşımında geri deneme yapar; genellikle artan aralıklarla (dakikalar, sonra saatler) ve bir kesme süresiyle (bir veya iki gün) devam eder. Bu kulağa rahatlatıcı gelse de hem kullanıcı deneyimini hem de destek hikâyenizi değiştirir.

Kullanıcı tarafında, yeniden denemeler temiz bir "ödeme onaylandı" anını garip bir gecikmeye dönüştürebilir. Müşteri sağlayıcı sayfasında başarı görür ama uygulamanız "beklemede" kalır; bir sonraki deneme gelene kadar beklenir. Tersi de olur: bir saatlik kesinti sonrası yeniden denemeler patlama halinde gelir ve eski olaylar topluca "yakalanır".

Yeniden denemeler çalıştığında destek genellikle daha az ticket alır, ama kalan ticket'lar daha zordur. Tek bir bariz hatayla uğraşmak yerine, birden fazla teslimat, farklı yanıt kodları ve orijinal eylem ile nihai başarı arasındaki uzun boşlukla uğraşırsınız. Bu boşluğu açıklamak zordur.

Kesinti birikimi, yavaş işleyicilerin zaman aşımına devam etmesi veya sistem idempotent değilse çift teslimatların çift oluşturma veya çift ücretlendirme tetiklemesi gibi durumlar yeniden denemelerin gerçek operasyonel ağrılarına yol açar. Ayrıca dalgalı davranışı saklayıp bir örüntü olana dek gizleyebilirler.

Yeniden denemeler, hata işleme basit olduğunda genellikle yeterlidir: parasal olmayan güncellemeler, iki kez uygulanması güvenli olan eylemler ve küçük gecikmenin kabul edilebilir olduğu olaylar. Olay para hareketi yapabiliyorsa veya kalıcı kayıtlar oluşturabiliyorsa, webhook yeniden denemeleri ve manuel tekrar oynatma konusundaki karar kolaylıktan çok kontrole dönmelidir.

Manuel tekrar oynatma: kontrol, hesap verebilirlik ve ödünler

Manuel tekrar oynatma, sağlayıcının yeniden deneme takvimine güvenmek yerine bir kişinin webhook olayını yeniden işlemesine karar vermesi demektir. Bu kişi bir destek temsilcisi, müşteri tarafında bir yönetici veya (düşük riskli durumlarda) "Tekrar Dene" butonuna tıklayan son kullanıcı olabilir. Yeniden oynatma insan kontrolünü hıza tercih eder.

Kullanıcı deneyimi karışıktır. Yüksek değerli olaylar için bir tekrar oynatma düğmesi, bir vaka için bir sonraki deneme penceresini beklemeden hızlıca düzeltebilir. Ancak pek çok problem, birileri farkedip harekete geçene kadar daha uzun süre bekleyebilir.

Destek iş yükü genellikle artar çünkü tekrar oynatma sessiz hataları ticket'a dönüştürür ve takip gerektirir. Avantajı ise netliktir: destek neyin tekrar oynatıldığını, ne zaman, kim tarafından ve neden görebilir. Bu denetim izi para, erişim veya yasal kayıtlar söz konusu olduğunda önemlidir.

Güvenlik zor kısımdır. Bir tekrar oynatma aracı yetkilendirilmiş ve dar kapsamlı olmalıdır:

• Sadece güvenilen roller tekrar oynatabilir ve sadece belirli sistemler için.
• Tekrar oynatmalar "her şeyi tekrar oynat" değil, tek bir olaya yönelik olmalıdır.
• Her tekrar oynatma neden, aktör ve zaman damgası ile kaydedilmelidir.
• UI'da hassas yük içerikleri maskelenmelidir.
• Kötüye kullanım ve kazara spam'i önlemek için hız sınırlamaları olmalıdır.

Manuel tekrar oynatma genellikle faturalar oluşturma, hesaplar sağlama, iadeler veya çift ücretlendirme/çift kayıt oluşturma riski taşıyan her türlü yüksek riskli eylem için tercih edilir. Ayrıca destek veya operasyon ekiplerinin müşteri hesabını ve sağlayıcının panelini kontrol etmesi gereken takımlar için uygundur. Son kullanıcıların tekrar oynatmasına izin vermek düşük riskli eylemler için işe yarayabilir, ama aynı zamanda tekrarlayan tıklamalar ve daha fazla çoğaltmaya yol açabilir.

Yeniden denemeler ile tekrar oynatma arasında nasıl seçim yapılır

Otomatik yeniden denemeler ile manuel tekrar oynatma arasında seçim tek bir kural değildir. En güvenli yaklaşım genellikle karışımdır: düşük riskli olayları otomatik olarak yeniden deneyin, para veya karmaşık çoğaltma riski olanlar için kasıtlı bir tekrar oynatma gerektirin.

Her webhook olayını risk açısından sınıflandırarak başlayın. Bir teslimat durum güncellemesi gecikirse can sıkıcıdır ama nadiren kalıcı zarar verir. payment_succeeded veya create_subscription gibi bir olay yüksek risktir çünkü ekstra bir çalıştırma çift ücretlendirmeye veya çift kayıt oluşturmaya yol açabilir.

Sonra kimin kurtarmayı tetikleyebileceğine karar verin. Sistem tetikli yeniden denemeler, eylem güvenli ve hızlıysa mükemmeldir. Hassas olaylar için destek veya operasyonun, müşterinin hesabını ve sağlayıcının panelini kontrol ettikten sonra tekrar oynatma tetiklemesi genellikle daha iyidir. Son kullanıcıların tekrar oynatmasına izin vermek düşük riskli eylemler için işe yarayabilir ama tekrar tekrar tıklama sorununu yaratabilir.

Zaman pencereleri de önemlidir. Yeniden denemeler genellikle dakikalar veya saatler içinde olur çünkü geçici sorunları iyileştirmek içindir. Manuel tekrar oynatmalara daha uzun izin verilebilir ama sonsuza kadar değil. Yaygın bir kural: tekrar oynatma iş bağlamı hala geçerliyken (sipariş gönderilmeden, fatura dönemi kapanmadan önce) izin verin, sonra daha dikkatli bir düzeltme isteyin.

Olay türü başına kısa kontrol listesi:

• İki kez çalıştırılırsa en kötü ne olur?
• Sonucu kim doğrulayabilir (sistem, destek, operasyon, kullanıcı)?
• Ne kadar hızlı başarılı olmalı (saniyeler, dakikalar, günler)?
• Kabul edilebilir çoğaltma oranı nedir (para için neredeyse sıfır)?
• Her vaka için kabul edilebilir destek zamanı ne kadar?

Sisteminizi bir create_invoice webhook'unu kaçırdıysa kısa bir yeniden deneme döngüsü yeterli olabilir. charge_customer kaçırıldıysa, açık bir denetim izi ve idempotency kontrolleri olan manuel tekrar oynatma tercih edin.

No-code bir araçta (örneğin AppMaster) akışı kuruyorsanız, her webhook'u bir iş süreci olarak ele alın: güvenli adımlar için otomatik yeniden deneme, yüksek riskli adımlar için onay ve ne olacağını gösteren ayrı bir tekrar oynatma eylemi ekleyin.

Idempotency ve çoğaltma önleme temelleri

Idempotency, aynı webhook'u birden fazla kez güvenle işleyebilmek demektir. Sağlayıcı yeniden denerse veya bir destek görevlisi bir olayı tekrar oynatırsa, sonuç tek işlemle aynı olmalıdır. Bu, Webhook yeniden denemeleri ve manuel tekrar oynatma arasında güvenli kurtarmanın temelidir.

Güvenilir bir idempotency anahtarı seçmek

Soru şu: "Bunu zaten uyguladık mı?" İyi seçenekler, göndericinin ne sağladığına bağlıdır:

• Sağlayıcı olay kimliği (stabil ve benzersiz olduğunda en iyisi)
• Sağlayıcı teslimat kimliği (yeniden denemeleri teşhis etmek için faydalı, ama her zaman olayla aynı olmayabilir)
• Sizin bileşik anahtarınız (örneğin: sağlayıcı + hesap + nesne ID + olay tipi)
• Ham yükün hash'i (başka seçenek yoksa, ama boşluk ve alan sıralamasına dikkat)
• Sağlayıcıya döndüğünüz üretilmiş bir anahtar (sadece bunu destekleyen API'lerde çalışır)

Eğer sağlayıcı benzersiz ID garanti etmiyorsa, benzersizlik için yükü güvensiz olarak değerlendirin ve iş anlamına dayalı bir bileşik anahtar oluşturun. Ödemeler için bu, charge veya invoice ID artı olay tipi olabilir.

Çoğaltmayı nerede zorunlu kılmalı

Tek bir katmana güvenmek risklidir. Daha güvenli bir tasarım birden fazla noktada kontrol eder: webhook uç noktasında (hızlı reddetme), iş mantığında (durum kontrolleri) ve veritabanında (kesin garanti). Veritabanı son kilittir: işlenmiş anahtarları benzersiz kısıtla saklayın ki iki işçi aynı olayı aynı anda uygulamasın.

Sırası karışmış olaylar ayrı bir sorundur. Çoğaltma yinelemeleri engeller ama eski güncellemelerin daha yeni durumu üzerine yazmasını engellemez. Basit korumalar kullanın: zaman damgaları, sıra numaraları veya "sadece ileri taşı" kuralları. Örnek: bir sipariş zaten "Paid" olarak işaretlendiyse, daha sonra gelen bir "Pending" güncellemesini görmezden gelin.

No-code bir yapıda (örneğin AppMaster) processed_webhooks tablosu modelleyip idempotency anahtarına benzersiz indeks ekleyebilirsiniz. Ardından Business Process'iniz önce kaydı oluşturmaya çalışsın. Başarısız olursa işleme durun ve gönderene başarı döndürün.

Adım adım: varsayılan olarak güvenli bir tekrar oynatma aracı tasarlamak

İyi bir tekrar oynatma aracı bir şeyler ters gittiğinde paniği azaltır. Tekrar oynatma, aynı güvenli işleme yolunu yeniden çalıştırdığında ve çoğaltmayı önleyen korumalarla birlikte olduğunda en iyi sonucu verir.

1) Önce yakala, sonra işle

Gelen her webhook'u bir denetim kaydı olarak ele alın. Ham gövdeyi geldiği gibi, imza ve zaman damgası başlıkları ile teslim meta verisini (alınma zamanı, kaynak, varsa deneme sayısı) kaydedin. Normalleştirilmiş bir olay kimliği de saklayın; gerekirse türetin.

İmzayı doğrulayın ama iş mantığını çalıştırmadan önce mesajı kalıcılaştırın. İşlem yarıda kesilirse bile orijinal olay elinizde olur ve ne geldiğini kanıtlayabilirsiniz.

2) İşleyiciyi idempotent yapın

İşlemciniz iki kez çalıştırılsa bile aynı nihai sonucu üretebilmelidir. Kayıt oluşturma, kart çekme veya erişim sağlama gibi eylemlerden önce bu olayın (veya işsel işlemin) zaten başarılı olup olmadığını kontrol etmelidir.

Temel kuralı basit tutun: bir olay id'si + bir eylem = bir başarılı sonuç. Önceki bir başarı görülürse, eylemi tekrarlamadan tekrar başarı dönün.

3) İnsanların kullanabileceği şekilde sonuçları kaydedin

Tekrar oynatma aracı ancak geçmişi ne kadar iyi saklarsa o kadar işe yarar. İşleme durumunu ve desteğin anlayacağı kısa bir nedeni saklayın:

• Başarılı (oluşturulan kayıt ID'leriyle)
• Yeniden denenebilir hata (zaman aşımı, üst akış geçici sorunları)
• Kalıcı hata (geçersiz imza, eksik zorunlu alan)
• Yoksayıldı (çoğaltma, sıra karışıklığı)

4) Tekrar oynatma, işleyiciyi yeniden çalıştırmalı; "yeniden oluşturma" yapmamalı

Tekrar oynatma düğmesi, saklanmış yükle aynı işleyiciyi çağıran bir iş kuyruğuna iş eklemeli. UI'nin doğrudan "şimdi sipariş oluştur" gibi yazma işlemleri yapmasına izin vermeyin; bu dedup'ı atlar.

Yüksek riskli olaylar (ödemler, iadeler, plan değişiklikleri) için bir önizleme modu ekleyin: ne değişeceğini, hangi kayıtların oluşturulacağını/güncelleneceğini ve hangilerinin çoğaltma nedeniyle atlanacağını gösterin.

AppMaster gibi bir araçta bunu kuruyorsanız, tekrar oynatma eylemini her zaman idempotent mantıktan geçen tek bir backend uç noktası veya iş süreci olarak tutun, admin ekranından tetiklendiğinde bile.

Destek ekibinin sorunları hızlı çözebilmesi için ne saklanmalı

Bir webhook başarısız olduğunda destek, kayıtlarınız ne kadar netse o kadar hızlı yardımcı olabilir. Eğer tek ipucu "500 hatası" ise sonraki adım tahmin yürütme olur ve tahminler riskli tekrar oynatmalara yol açar.

İyi saklama, korkutucu bir olayı rutin bir kontrole çevirir: olayı bulun, ne olduğunu görün, güvenle tekrar oynatın ve ne değiştiğini kanıtlayın.

Her gelen olay için küçük, tutarlı bir webhook teslimat kaydı ile başlayın. Bunu iş verilerinizden (siparişler, faturalar, kullanıcılar) ayrı tutun ki başarısızlıkları üretim durumuna dokunmadan inceleyebilin.

En azından şunları saklayın:

• Sağlayıcıdan gelen Event ID, kaynak/sistem adı ve uç nokta veya işleyici adı
• Alınma zamanı, güncel durum (yeni, işleniyor, başarılı, başarısız) ve işleme süresi
• Deneme sayısı, bir sonraki deneme zamanı (varsa), son hata mesajı ve hata tipi/kodu
• Olayın nesnelerinizle ilişkilendiren correlation ID'leri (user_id, order_id, invoice_id, ticket_id) ve sağlayıcı ID'leri
• Yük işleme detayları: ham yük (veya şifrelenmiş blob), yük hash'i ve şema/sürüm

Correlation ID'ler desteği etkili kılar. Bir destek görevlisi "Order 18431" aradığında, ona dokunan her webhook'u, oluşturulamayanlar dahil, hemen görmelidir.

Manuel işlemler için bir denetim izi tutun. Birisi bir olayı tekrar oynattığında, kim, ne zaman, nereden (UI/API) ve sonuç kaydedilsin. Kısa bir değişiklik özeti (örneğin "fatura ödendi olarak işaretlendi" veya "müşteri kaydı oluşturuldu") bile itirazları azaltır.

Saklama süresi önemlidir. Loglar ucuzdur ta ki pahalı olana dek; ayrıca yükler kişisel veri içerebilir. Açık bir kural belirleyin (örneğin tam yük 7–30 gün, meta veriler 90 gün) ve buna uyun.

Yönetici ekranınız cevapları bariz hale getirmeli. Event ID ve correlation ID ile arama, durum ve "dikkat gerektiriyor" filtreleri, denemelerin ve hataların zaman çizelgesi, onay ve görünür bir idempotency anahtarı ile güvenli tekrar oynatma düğmesi ve iç notlar için dışa aktarılabilir detaylar eklemek yardımcı olur.

Çift ücretlendirmeler ve çift kayıtlardan kaçınma

Webhook yeniden denemeleri ve manuel tekrar oynatma konusundaki en büyük risk yeniden denemenin kendisi değil; yan etkileri tekrarlamaktır: kartı iki kez çekmek, iki abonelik oluşturmak veya aynı siparişi iki kez göndermek.

Daha güvenli bir tasarım "para hareketini" ve "işin yerine getirilmesini" ayırır. Ödemelerde bunları ayrı adımlar olarak ele alın: bir ödeme niyeti (veya yetkilendirme) oluşturun, yakalayın, sonra fulfillment yapın (siparişi ödenmiş olarak işaretle, erişimi aç, gönder). Bir webhook iki kez gelirse ikinci çalıştırma "zaten yakalandı" veya "zaten yerine getirildi" görmeli ve durmalıdır.

Charge oluştururken sağlayıcı tarafı idempotency'sini kullanın. Çoğu ödeme sağlayıcısı aynı isteğe aynı sonucu döndüren bir idempotency anahtarı destekler; bunu saklayın ki yeniden denemede aynı sonucu alabilesiniz.

Veritabanınız içinde de kayıt oluşturmayı idempotent hale getirin. En basit koruma, dış olay ID'si veya nesne ID'si (charge_id, payment_intent_id, subscription_id gibi) üzerinde unique constraint koymaktır. Aynı webhook tekrar geldiğinde insert güvenli şekilde başarısız olur ve var olan kaydı yükleyip devam edersiniz.

Durum geçişlerini yalnızca ileri taşıyacak şekilde koruyun. Örneğin, bir siparişi pending'den paid'e yalnızca halen pending ise taşıyın. Eğer zaten paid ise hiçbir şey yapmayın.

Kısmi hatalar yaygındır: para başarılı oldu ama veritabanı yazımı başarısız oldu. Bunun için önce kalıcı bir "alınan olay" kaydı kaydetmek gibi tasarım yapın. Destek olayı daha sonra tekrar oynattığında, işleyici eksik kalan adımları tekrar yapıp ödeme yapmadan tamamlayabilsin.

Hâlâ işler ters giderse, telafi edici eylemler tanımlayın: yetkilendirmeyi iptal et, yakalanmış bir ödemeyi iade et veya fulfillment'ı geri al. Bir tekrar oynatma aracı, bir insanın sonucu tahmin etmeden düzeltebilmesi için bu seçenekleri açıkça sunmalıdır.

Yaygın hatalar ve tuzaklar

Çoğu kurtarma planı bir webhook'u tekrar basılabilecek bir düğme gibi ele aldığı için başarısız olur. İlk deneme zaten bir şeyi değiştirdiyse, ikinci deneme kartı iki kez çekebilir veya çift kayıt oluşturabilir.

Yaygın bir tuzak, orijinal yükü önce kaydetmeden olayları tekrar oynatmaktır. Sonradan destek tekrar oynat düğmesine bastığında, bugünün yeniden oluşturulmuş verisini gönderiyor olabilir; bu, denetimleri bozar ve hataları yeniden üretmeyi zorlaştırır.

Bir diğer tuzak zaman damgalarını idempotency anahtarı olarak kullanmaktır. İki olay aynı saniyeyi paylaşabilir, saatler kayabilir ve tekrar oynatmalar saatler sonra olabilir. İdempotency anahtarınız sağlayıcının benzersiz olay ID'sine (veya yükün stabil, benzersiz bir hash'ine) bağlı olmalıdır, zaman damgasına değil.

Destek ticket'larına dönüşen kırmızı bayraklar:

• Durum kontrolü olmadan tekrarlanan non-idempotent eylemler (örnek: "create invoice" tekrar çalışır ve zaten bir fatura vardır)
• Yeniden denenebilir hatalar (zaman aşımı, 503) ile kalıcı hataların (geçersiz imza, eksik alan) ayrılmaması
• Herkesin kullanabildiği bir tekrar oynatma düğmesi; rol kontrolü, neden alanı ve denetim izi yok
• Gerçek hataları saklayan ve aşağı akış sistemlerine sürekli vuran otomatik yeniden deneme döngüleri
• Denemeleri sınırlamayan veya aynı olay sürekli başarısız oluyorsa insanı uyarmayan "fire and forget" yeniden denemeler

Ayrıca karışık politikalar konusunda dikkatli olun. Ekipler bazen koordinasyonsuz olarak her iki sistemi de etkinleştirir ve aynı olayı iki farklı mekanizma ile yeniden göndermeye başlarlar.

Basit bir senaryo: ödeme webhook'u veritabanınızı kaydederken zaman aşımına uğrar. Eğer yeniden deneme "müşteriyi tekrar ücretlendir" yerine "ücretin varlığını doğrula, sonra siparişi ödenmiş olarak işaretle" yaparsa karışıklık önlenir. Güvenli tekrar oynatma araçları her zaman önce mevcut durumu kontrol eder, sonra yalnızca eksik adımı uygular.

Yayına almadan önce hızlı kontrol listesi

Kurtarmayı bir özellik olarak ele alın, sonradan eklenen bir şey olarak değil. Her zaman güvenle tekrar çalıştırabilmeli ve ne olduğunu açıklayabilmelisiniz.

Pratik bir ön yayın kontrol listesi:

• Her webhook olayını geldiği anda kalıcılaştırın, iş mantığı çalışmadan önce ham gövde, başlıklar, alınma zamanı ve stabil bir dış olay ID'si saklayın.
• Her event için tek bir stabil idempotency anahtarı kullanın ve bunu tüm yeniden denemeler ve manuel tekrar oynatmalar için yeniden kullanın.
• Duplicasyonu veritabanı seviyesinde zorunlu kılın. Dış ID'ler (ödeme ID'si, fatura ID'si, olay ID'si) üzerinde unique constraint koyun ki ikinci bir çalıştırma ikinci bir satır yaratamasın.
• Tekrar oynatmayı açık ve öngörülebilir yapın. Ne olacağını gösterin ve bir ödeme yakalama veya geri dönüşü olmayan bir provisioning gibi riskli eylemler için onay isteyin.
• Başlangıçtan sona açık durumları izleyin: received, processing, succeeded, failed, ignored. Son hata mesajı, deneme sayısı ve kim tekrar oynattı bilgilerini dahil edin.

Bunu tamamlamadan önce destek sorularını test edin. Birisi bir dakika içinde şu soruları cevaplayabiliyor mu: ne oldu, neden başarısız oldu ve tekrar oynatma sonrası ne değişti?

AppMaster ile inşa ediyorsanız, önce Event log'u Data Designer'da modelleyin, sonra idempotency'yi kontrol eden güvenli bir tekrar oynatma eylemi içeren küçük bir admin ekran ekleyin. Bu sıra, "güvenliği sonra ekleriz" durumunun "hiç güvenli tekrar oynatma yok" olmasına dönüşmesini engeller.

Örnek: bir ödeme webhook'u bir kez başarısız olup sonra başarılı oluyor

Bir müşteri ödeme yapar ve ödeme sağlayıcınız payment_succeeded webhook'u gönderir. Aynı anda veritabanınız yoğunluk altında ve yazma zaman aşımına uğrar. Sağlayıcı 500 yanıtı alır ve daha sonra yeniden dener.

Güvenli kurtarma şöyle görünmelidir:

• 12:01 Olay denemesi #1 evt_123 ID ile gelir. İşleyiciniz başlar; sonra INSERT invoice sırasında DB zaman aşımına uğrar. 500 döndürürsünüz.
• 12:05 Sağlayıcı aynı evt_123 ile tekrar dener. İşleyiciniz önce dedupe tablosunu kontrol eder, uygulandığını görmez, faturayı yazar, evt_123'ü işlendi olarak işaretler ve 200 döner.

Önemli kısmı: sisteminiz her iki teslimatı da aynı olay olarak değerlendirmelidir. Fatura bir kez oluşturulmalı, sipariş bir kez "Paid" olmalı ve müşteri bir kere makbuz almalıdır. Sağlayıcı başarı sonrası tekrar denese bile işleyiciniz evt_123'ü zaten işlenmiş olarak okuyup no-op ile temiz 200 döndürmelidir.

Loglarınız destekçiyi endişelendirmek yerine güven vermeli. İyi bir kayıt, deneme #1'in "DB zaman aşımı" ile başarısız olduğunu, deneme #2'nin başarılı olduğunu ve nihai durumun "uygulandı" olduğunu göstermelidir.

Eğer bir destek elemanı evt_123 için tekrar oynatma aracını açarsa, sıkıcı olmalıdır: "Zaten uygulandı" gösterir ve tekrar oynatma butonuna basılırsa yalnızca güvenli bir kontrolü yeniden çalıştırır; yan etkileri tekrarlamaz. İkinci fatura yok, ikinci e-posta yok, çift ücretlendirme yok.

Sonraki adımlar: pratik bir kurtarma akışı inşa edin

Aldığınız her webhook olay tipini yazın, sonra her birini düşük risk veya yüksek risk olarak işaretleyin. "Kullanıcı kaydoldu" genelde düşük risktir. "Payment succeeded", "refund issued" ve "subscription renewed" gibi olaylar yüksek risktir çünkü hata para kaybına veya çözülmesi zor karışıklıklara yol açabilir.

Sonra çalışan en küçük kurtarma akışını oluşturun: gelen her olayı saklayın, idempotent bir işleyici ile işleyin ve destek için minimal bir tekrar oynatma ekranı sağlayın. Amaç gösterişli bir pano değil; şu soruyu güvenle hızlıca cevaplayabilmek olmalı: "Olayı aldık mı, işledik mi ve eğer işlemediysek tekrar denerken hiçbir şeyi çoğaltmadan yapabilir miyiz?"

Basit ilk sürüm:

• Ham yükü, sağlayıcı olay ID'si, alınma zamanı ve güncel durumu kalıcılaştırın.
• Aynı olayın ikinci bir ücret veya ikinci kayıt yaratmasını engelleyecek idempotency'yi zorunlu kılın.
• Tek bir olay için işleyiciyi yeniden çalıştıran bir tekrar oynatma eylemi ekleyin.
• Son hatayı ve son işleme denemesini gösterin ki destek ne olduğunu bilsin.

Bu işe yarayınca, risk seviyesine uygun korumalar ekleyin. Yüksek riskli olaylar daha sıkı izinler, daha net onaylar (örneğin "Tekrar oynatma fulfillment tetikleyebilir. Devam edilsin mi?"), ve kim ne zaman tekrar oynattı gibi tam denetim izi gerektirsin.

Ağır kodlama olmadan bunu kurmak isterseniz, AppMaster (appmaster.io) desen için pratik bir uyum sağlar: webhook olaylarını Data Designer'da saklayın, idempotent iş akışlarını Business Process Editor'da uygulayın ve UI builderlarla iç tekrar oynatma yönetim paneli yayınlayın.

Dağıtımı erken kararlaştırın çünkü operasyonları etkiler. Bulut veya self-hosted fark etmeksizin, destek ekibinin loglara ve tekrar oynatma ekranına güvenli erişimi olmalı ve saklama politikası fatura itirazlarını ve müşteri sorularını çözmek için yeterli geçmişi tutmalıdır.