Webhook güvenilirliği kontrol listesi: yeniden denemeler, idempotentlik, yeniden oynatma

Gerçek projelerde webhookların neden güvenilmez hissi verdiği

Webhook basit bir anlaşmadır: bir sistem bir şey olduğunda başka bir sisteme HTTP isteği gönderir. "Sipariş gönderildi", "talep güncellendi", "cihaz çevrimdışına geçti". Temelde uygulamalar arasında web üzerinden iletilen bir push bildirimi gibidir.

Demolarda güvenilir görünürler çünkü mutlu yol hızlı ve temizdir. Gerçek işte webhooklar kontrolünüzde olmayan sistemlerin arasında oturur: CRM'ler, kargo sağlayıcıları, yardım masaları, pazarlama araçları, IoT platformları, hatta başka bir ekip tarafından yönetilen dahili uygulamalar. Ödeme dışındaki alanlarda genellikle olgun teslimat garantilerini, sabit olay şemalarını ve tutarlı yeniden deneme davranışını kaybedersiniz.

İlk belirtiler genellikle kafa karıştırıcıdır:

• Çift olaylar (aynı güncelleme iki kez gelmesi)
• Eksik olaylar (bir şey değişti ama hakkında haberiniz olmadı)
• Gecikmeler (bir güncelleme dakikalar veya saatler sonra gelmesi)
• Sıra dışı olaylar ("kapandı" güncellemesi "açıldı"dan önce gelmesi)

Arızalı üçüncü taraf sistemleri bunu rastgele hissettirir çünkü hatalar her zaman yüksek sesle olmaz. Bir sağlayıcı zaman aşımına uğrayabilir ama isteğinizi yine de işlemiş olabilir. Bir yük dengeleyici, gönderen zaten yeniden denediğinde bağlantıyı koparabilir. Ya da sistemleri kısa süreliğine düşüp sonra eski olayları bir seferde gönderebilir.

Bir gün kargo ortağınız "teslim edildi" webhokları gönderiyor. Bir gün alıcınız 3 saniye boyunca yavaş çalışır, bu yüzden sağlayıcı yeniden dener. İki teslimat alırsınız, müşterinize iki e-posta gider ve destek karışır. Ertesi gün bir kesinti yaşarlar ve asla yeniden denemezler, bu yüzden "teslim edildi" hiç gelmez ve panonuz takılı kalır.

Webhook güvenilirliği tek bir mükemmel istekle ilgili değil; daha çok dağınık gerçeğe göre tasarlamakla ilgilidir: yeniden denemeler, idempotentlik ve daha sonra ne olduğunu yeniden oynatma ve doğrulama yeteneği.

Üç yapı taşı: yeniden denemeler, idempotentlik, yeniden oynatma

Webhooklar iki yönde gelir. Gelen webhoklar (inbound) başkalarının sizden aldığı çağrılardır (bir ödeme sağlayıcısı, CRM, kargo aracı). Giden webhoklar (outbound) sisteminizde bir şey değiştiğinde müşteri veya ortağınıza gönderdiğiniz çağrılardır. Her ikisi de kodunuzla ilgisi olmayan nedenlerle başarısız olabilir.

Yeniden denemeler bir başarısızlıktan sonra olanlardır. Bir gönderici zaman aşımı, 500 hatası, bağlantı kopması veya yeterince hızlı yanıt almama nedeniyle yeniden deneyebilir. İyi yeniden denemeler beklenen davranıştır, nadir bir kenar durumu değil. Amaç olayı alıcıyı bunaltmadan veya yan etkiyi tekrar yaratmadan geçirmek.

Idempotentlik kopyaları nasıl güvenli hale getirdiğinizdir. Bu "bir kez yap, tekrar gelse bile" demektir. Aynı webhook tekrar gelirse bunu tespit eder ve iş eylemini ikinci kez çalıştırmadan başarı yanıtı dönersiniz (örneğin ikinci bir fatura oluşturmayın).

Yeniden oynatma kurtarma düğmenizdir. Bu, bir hatayı düzelttikten veya bir ortağın kesintisi sonrasında geçmiş olayları maksatlı, kontrollü şekilde tekrar işlemektir. Yeniden oynatma, yeniden denemelerden farklıdır: yeniden denemeler otomatik ve anlıkken, yeniden oynatma kasıtlıdır ve genellikle saatler veya günler sonra olur.

Webhook güvenilirliği istiyorsanız, birkaç basit hedef belirleyin ve bunların etrafında tasarlayın:

• Kayıp olay yok (her zaman ne geldiğini veya ne göndermeye çalıştığınızı bulabilirsiniz)
• Güvenli kopyalar (yeniden denemeler ve yeniden oynatmalar çift ücretlendirme, çift oluşturma veya çift e-posta göndermesin)
• Net denetim izi ("ne oldu?" sorusunu hızlıca cevaplayabilin)

Üçüne de pratik destek sağlamak için her webhook denemesini bir durum ve benzersiz bir idempotency anahtarı ile saklamak iyidir. Birçok ekip bunu küçük bir "webhook inbox/outbox" tablosu olarak kurar.

Gelen webhooklar: tekrar kullanabileceğiniz bir alıcı akışı

Çoğu webhook sorunu gönderen ve alıcının farklı saatlerde çalışmasından kaynaklanır. Alıcı olarak göreviniz öngörülebilir olmaktır: hızlıca kabul edin, ne geldiğini kaydedin ve güvenli şekilde işleyin.

"Kabul et" ile "işi yap"ı ayırın

HTTP isteğini hızlı tutan ve gerçek işi başka yere taşıyan bir akışla başlayın. Bu zaman aşımı süresini azaltır ve yeniden denemeleri çok daha az acı verici hale getirir.

• Hızlı onaylayın. İstek kabul edilebilir olduğunda mümkün olan en kısa sürede 2xx döndürün.
• Temelleri kontrol edin. İçerik tipini, gerekli alanları ve ayrıştırmayı doğrulayın. Webhook imzalıysa imzayı burada doğrulayın.
• Ham olayı kalıcılaştırın. Gövdeyi ve daha sonra ihtiyaç duyacağınız başlıkları (imza, olay ID) alın; alınma zaman damgası ve "alındı" gibi bir durumla saklayın.
• İşi kuyruğa alın. Arka plan işleme için bir görev oluşturun ve sonra 2xx döndürün.
• Belirgin sonuçlarla işleyin. Yan etkiler başarılı olduktan sonra olayı "işlendi" olarak işaretleyin. Başarısız olursa nedenini ve yeniden denenip denenmemesi gerektiğini kaydedin.

"Hızlı yanıt" nasıl görünür

Gerçekçi bir hedef bir saniyenin altında yanıt vermektir. Gönderen belirli bir kod bekliyorsa onu kullanın (birçokları 200 kabul eder, bazıları 202 tercih eder). Gönderenin yeniden denememesi gereken durumlarda sadece 4xx döndürün (örneğin geçersiz imza).

Örnek: customer.created olayı veritabanınız yük altındayken gelir. Bu akışla yine ham olayı saklar, kuyruğa alır ve 2xx ile yanıt verirsiniz. Worker daha sonra yeniden denemesini kendi başına yapabilir; göndericinin yeniden göndermesine ihtiyaç yoktur.

Teslimatı bozmayan gelen güvenlik kontrolleri

Güvenlik kontrollerini yapmak değerlidir, ancak amaç kötü trafiği engellemek ama gerçek olayları engellememektir. Birçok teslimat sorunu alıcıların çok katı davranması veya yanlış yanıt dönmesinden kaynaklanır.

Göndericiyi kanıtlamayla başlayın. Tercihen imzalı istekler (HMAC imza başlığı) veya başlıkta paylaşılan gizli bir token kullanın. Büyük işleri yapmadan önce bunu doğrulayın ve eksik veya yanlışsa hızlıca başarısız olun.

Durum kodlarıyla dikkatli olun çünkü bunlar yeniden denemeleri kontrol eder:

• Kimlik doğrulama hataları için 401/403 döndürün ki gönderici sonsuza dek deneme yapmasın.
• Bozuk JSON veya gerekli alanların eksikliği için 400 döndürün.
• Sadece servisin geçici olarak kabul edemediği durumlarda 5xx döndürün.

IP izin listeleri yardımcı olabilir, ama yalnızca sağlayıcının kararlı, belgelenmiş IP aralıkları varsa. IP'leri sık değişiyorsa (veya büyük bir bulut havuzu kullanıyorlarsa), izin listeleri gerçek webhookları sessizce düşürebilir ve bunu ancak çok sonra fark edebilirsiniz.

Sağlayıcı zaman damgası ve benzersiz olay ID'si içeriyorsa yeniden oynatma koruması ekleyebilirsiniz: çok eski mesajları reddedin ve yakın ID'leri takip ederek kopyaları tespit edin. Zaman penceresini küçük tutun, ancak saat farklılıklarının geçerli istekleri kırmaması için küçük bir tolerans verin.

Alıcı dostu bir güvenlik kontrol listesi:

• Büyük yükleri ayrıştırmadan önce imzayı veya paylaşılan gizli anahtarı doğrulayın.
• Maksimum gövde boyutu ve kısa bir istek zaman aşımı uygulayın.
• Kimlik hatası veya bozuk şema için 4xx, kabul edilen olaylar için 2xx ve gerçekten geçici sorunlar için 5xx kullanın.
• Zaman damgası kontrol ediyorsanız küçük bir tolerans penceresi bırakın (örneğin birkaç dakika).

Günlükleme için denetim izi tutun ama hassas verileri sonsuza dek saklamayın. Olay ID'si, gönderici adı, alma zamanı, doğrulama sonucu ve ham gövdenin bir karmasını saklayın. Eğer gövdeleri saklamanız gerekiyorsa, saklama sınırı koyun ve e-posta, token veya ödeme detayları gibi alanları maskeleyin.

Zararlı olmayan yeniden denemeler

Yeniden denemeler kısa arızayı başarılı teslimata çeviriyorsa iyidir. Trafiği çoğaltıp gerçek hataları saklıyorsa veya çoğaltmalara neden oluyorsa zararlıdır. Fark; neyi yeniden deneyeceğiniz, denemeler arası boşluk ve ne zaman duracağınız konusunda net bir kurala sahip olmaktır.

Genel olarak, alıcının daha sonra muhtemelen başarılı olacağı durumlarda yeniden deneyin. Faydali bir zihniyet: "geçici" hatalarda yeniden dene, "siz yanlış bir şey gönderdiniz" durumlarında yeniden deneme.

Pratik HTTP sonuç modeli:

• Yeniden dene: ağ zaman aşımı, bağlantı hataları ve HTTP 408, 429, 500, 502, 503, 504
• Yeniden deneme: HTTP 400, 401, 403, 404, 422 -> yeniden denemeyin
• Duruma göre: HTTP 409 (bazen "kopya", bazen gerçek bir çakışma)

Boşluklama önemli. Bir yeniden deneme fırtınası yaratmamak için jitter ile üstel geri çekilme kullanın. Örnek: 5s, 15s, 45s, 2m, 5m bekleyin ve her seferine küçük rastgele bir ofset ekleyin.

Ayrıca maksimum yeniden deneme penceresi ve net bir kesme süresi belirleyin. Yaygın seçimler "24 saate kadar denemeye devam et" veya "10 kereden fazla deneme yapma" gibidir. Ondan sonra bunu teslimat problemi değil, kurtarma problemi olarak ele alın.

Bunun günlük işler için çalışması için olay kaydı şu bilgileri yakalamalıdır:

• Deneme sayısı
• Son hata
• Bir sonraki deneme zamanı
• Nihai durum (yeniden denemeyi durdurduğunuzda dead-letter durumu dahil)

Dead-letter öğeleri kolayca incelenebilir ve alttaki sorunu düzelttikten sonra güvenle yeniden oynatılabilir olmalıdır.

Uygulamada çalışan idempotentlik desenleri

Idempotentlik, aynı webhooku birden fazla kez güvenle işleyebilmeniz demektir. Yeniden denemeler ve zaman aşımı durumları bile gerçekleşeceği için güvenilirliği hızla artıran yöntemlerden biridir.

Kararlı bir anahtar seçin

Sağlayıcı size bir olay ID'si veriyorsa onu kullanın; en temiz seçenek budur.

Eğer olay ID yoksa, elinizdeki kararlı alanlardan türetilmiş bir anahtar oluşturun, örneğin:

• sağlayıcı adı + olay türü + kaynak ID + zaman damgasının karması, veya
• sağlayıcı adı + mesaj ID

Anahtarı ve küçük bir meta veri kümesini (alma zamanı, sağlayıcı, olay türü ve sonuç) saklayın.

Genellikle işe yarayan kurallar:

• Anahtarı zorunlu kabul edin. Oluşturamıyorsanız olayı tahmin etmek yerine karantinaya alın.
• Anahtarları bir TTL ile saklayın (örneğin 7–30 gün) ki tablo sonsuza dek büyümesin.
• İşleme sonucunu da saklayın (başarılı, başarısız, göz ardı edildi) ki kopyalar tutarlı cevap alsın.
• İki paralel isteğin ikisi de çalışmasın diye anahtar üzerinde unique kısıt koyun.

İş mantığını da idempotent yapın

İyi bir anahtar tablosu olsa bile gerçek operasyonlarınızın güvenli olması gerekir. Örnek: "sipariş oluştur" webhooku ilk denemede veritabanı insert’i zaman aşımına uğradıysa ikinci denemede ikinci bir sipariş oluşturulmamalıdır. Doğal iş tanımlayıcıları (external_order_id, external_user_id) ve upsert desenleri kullanın.

Sıra dışı olaylar yaygındır. user_updated önce user_created gelirse, "sadece event_version daha yeni ise uygula" veya "only update if updated_at daha yeni" gibi bir kural belirleyin.

Farklı gövdelere sahip kopyalar en zor durumdur. Önceden karar verin:

• Anahtar eşleşiyor ama gövde farklıysa sağlayıcı hatası sayıp uyarın.
• Anahtar eşleşiyor ve gövde yalnızca ilgisiz alanlarda farklıysa yok sayın.
• Sağlayıcıya güvenemiyorsanız, tam gövde karmasına dayalı türetilmiş bir anahtar kullanın ve çakışmaları yeni olay olarak işleyin.

Amaç basit: bir gerçek dünya değişikliği bir gerçek dünya sonucu üretmeli, mesajı üç kez görseniz bile.

Kurtarma için yeniden oynatma araçları ve denetim günlükleri

Bir ortak sistem dalgalanıyorsa, güvenilirlik mükemmel teslimattan çok hızlı kurtarmayla ilgilidir. Yeniden oynatma aracı "bazı olayları kaybettik"i rutin bir düzeltmeye çevirir.

Her webhookun yaşam döngüsünü izleyen bir olay günlüğü ile başlayın: alındı, işlendi, başarısız oldu veya göz ardı edildi. Bunu zaman, olay türü ve korelasyon ID ile aranabilir tutun ki destek "18432 numaralı siparişe ne oldu?" sorusunu hızla cevaplayabilsin.

Her olay için aynı kararı tekrar çalıştırmak üzere yeterli bağlamı saklayın:

• Ham yük ve anahtar başlıkları (imza, olay ID, zaman damgası)
• Çıkardığınız normalize edilmiş alanlar
• İşleme sonucu ve hata mesajı (varsa)
• O sırada kullanılan iş akışı veya eşleme versiyonu
• Alma, başlama, bitiş zaman damgaları

Bunlar hazır olduktan sonra başarısız olaylar için bir "Yeniden Oynat" eylemi ekleyin. Butonun kendisinden ziyade güvenlik önlemleri önemlidir. İyi bir yeniden oynatma akışı önceki hatayı, yeniden oynatmada ne olacağını ve olayın yeniden çalıştırılmasının güvenli olup olmadığını gösterir.

Kazaları engelleyen korumalar:

• Yeniden oynatma öncesi gerekçe notu zorunlu kılın
• Yeniden oynatma izinlerini küçük bir rolle sınırlayın
• Yeniden oynatma, ilk denemede kullanılan aynı idempotentlik kontrollerinden geçsin
• Yeniden oynatmaları oran sınırlamasıyla kontrol edin ki bir olaylar yığını sırasında yeni bir spike yaratılmasın
• Yazmadan doğrulayan isteğe bağlı bir "kuru çalışma" modu sunun

İnsanların müdahalesi genellikle birden fazla olayı içerdiğinden, zaman aralığına göre yeniden oynatma desteği sağlayın (ör. "10:05 ile 10:40 arasındaki tüm başarısız olayları yeniden oynat"). Kim hangi olayı ne zaman ve neden yeniden oynattığını kaydedin.

Giden webhooklar: denetlenebilir bir gönderici akışı

Giden webhooklar sıkıcı nedenlerle başarısız olur: alıcı yavaş, kısa süreli kesinti, DNS sorunu veya uzun istekleri koparan bir proxy. Güvenilirlik, her gönderimi tek seferlik HTTP çağrısı olarak değil, izlenen, tekrarlanabilir bir iş olarak ele almaktan gelir.

Öngörülebilir kalan bir gönderici akışı

Her olaya kararlı, benzersiz bir olay ID'si verin. Bu ID yeniden denemeler, yeniden oynatmalar ve hatta servis yeniden başlatmaları boyunca aynı kalmalıdır. Her deneme için yeni bir ID oluşturursanız, alıcının çoğaltmayı ortadan kaldırmasını ve sizin denetimi zorlaştırırsınız.

Sonra her isteği imzalayın ve bir zaman damgası ekleyin. Zaman damgası alıcıların çok eski istekleri reddetmesine yardımcı olur; imza ise payload'ın transit sırasında değiştirilmediğini kanıtlar. İmza kurallarını basit ve tutarlı tutun ki ortaklar tahmin etmeden uygulayabilsin.

Teslimatları sadece olay başına değil, her uç nokta için takip edin. Aynı olayı üç müşteriye gönderiyorsanız, her hedefin kendi deneme geçmişi ve nihai durumu olmalı.

Çoğu ekibin uygulayabileceği pratik bir akış:

• Olay kaydı oluşturun: olay ID, uç nokta ID, payload karması ve başlangıç durumu
• İmzalı, zaman damgalı ve bir idempotency anahtarı başlığı ile HTTP isteğini gönderin
• Her denemeyi kaydedin (başlama süresi, bitiş süresi, HTTP durumu, kısa hata mesajı)
• Zaman aşımı ve 5xx yanıtlarında yalnızca yeniden deneyin; üstel geri çekilme ve jitter kullanın
• Açık bir limite ulaşıldığında durun (maks deneme veya max yaş), sonra inceleme için başarısız olarak işaretleyin

Bu idempotency anahtarı başlığı, gönderici olsanız bile önemlidir. İlk isteği alıcının işlediği ama istemcinin 200 yanıtını alamadığı durumlarda alıcının çoğaltmayı engellemesine temiz bir yol sağlar.

Son olarak, hataları görünür yapın. "Başarısız" kaybolmuş demek olmamalı; yeterli bağlamla "duraklatılmış, güvenle yeniden oynatılabilir" anlamına gelmeli.

Örnek: dalgalanan bir partner sistemi ve temiz bir kurtarma

Destek uygulamanız ticket güncellemelerini partner sistemine gönderir ki onların ajanları aynı durumu görsün. Her bilet değiştiğinde (atanma, öncelik değişimi, kapatılma), ticket.updated gibi bir webhook olayı gönderirsiniz.

Bir öğleden sonra partnerin uç noktası zaman aşımına uğramaya başlar. İlk teslim denemeniz bekler, zaman aşımı sınırınıza takılır ve durumu "bilinmiyor" olarak kabul edersiniz (onlara ulaşmış da olabilir, ulaşmamış da). İyi bir yeniden deneme stratejisi bunu saniyede bir tekrar gönderip durmak yerine geri çekilmeyle yeniden dener. Olay aynı olay ID ile bir kuyruğa girer ve her deneme kayda geçirilir.

En can sıkıcı durum: idempotentlik kullanmıyorsanız partner kopyaları işleyebilir. Deneme #1 onlara ulaşmış olabilir ama yanıtınız geri dönmemiş olabilir. Deneme #2 daha sonra gelir ve ikinci bir "Bilet kapatıldı" eylemi yaratır; iki e-posta gönderilir veya iki zaman çizgisi girdisi oluşur.

Idempotentlikle her teslimat aynı olaydan türetilmiş bir idempotency anahtarı içerir (çoğunlukla olay ID'si). Partner bu anahtarı bir süre saklar ve tekrarlar için "zaten işlendi" yanıtı verir. Tahmin etmeyi bırakırsınız.

Partner geri geldiğinde, gerçekten kaybolan bir güncellemeyi düzeltmek için yeniden oynatma kullanırsınız (örneğin kesinti sırasında yapılan bir öncelik değişikliği). Denetim günlüğünüzden olayı seçip aynı payload ve idempotency anahtarıyla bir kez yeniden oynatırsınız; zaten almışlarsa da güvenlidir.

Olay sırasında loglar hikâyeyi açık hale getirmelidir:

• Olay ID, bilet ID, olay türü ve payload versiyonu
• Deneme numarası, zaman damgaları ve bir sonraki deneme zamanı
• Zaman aşımı mı yoksa non-2xx yanıt mı yoksa başarı mı
• Gönderilen idempotency anahtarı ve partnerin "kopya" raporu verip vermediği
• Kim yeniden oynattı, ne zaman ve nihai sonuç gibi bir yeniden oynatma kaydı

Sık yapılan hatalar ve tuzaklar

Çoğu webhook olayı tek bir büyük hatadan kaynaklanmaz. Trafik arttığında veya üçüncü taraf dalgalanma yaşadığında güvenilirliği sessizce bozan küçük seçimlerden kaynaklanır.

Post-mortem'lerde görülen tuzaklar:

• İstek işleyicisi içinde yavaş işleri yapmak (veritabanı yazma, API çağrıları, dosya yüklemeleri) ta ki gönderici zaman aşımına uğrayıp yeniden deneyene kadar
• Sağlayıcıların asla kopya göndermeyeceğini varsaymak; bunun sonucunda iki kez ücretlendirme, çift sipariş oluşturma veya iki e-posta gönderme
• Yanlış durum kodu döndürmek (olayı kabul etmediğiniz halde 200 dönmek ya da yeniden denendiğinde asla düzelmeyecek bozuk veri için 500 dönmek)
• Korelasyon ID, olay ID veya istek ID olmadan yayın yapmak; sonrasında logları müşteri raporlarıyla eşleştirmek saatler alır
• Sonsuza dek yeniden denemek; bu birikim oluşturur ve bir partner kesintisini kendi kesintinize dönüştürür

Basit bir kural işe yarar: hızlıca onayla, sonra güvenle işle. Kabul edip etmeye karar vermek için yalnızca gerekli olanı doğrulayın, olayı saklayın ve geri kalanını asenkron olarak yapın.

Durum kodları beklenenden daha fazla önem taşır:

• 2xx yalnızca olayı sakladığınızda (veya kuyruğa aldığınızda) ve ele alınacağından emin olduğunuzda kullanılmalı.
• 4xx gönderici düzeltemeyeceği girdi hataları veya auth hataları için kullanılmalı.
• 5xx sadece sunucunuzun geçici olarak kabul edemediği durumlar için kullanılmalı.

Bir yeniden deneme tavanı belirleyin. Sabit bir pencere (ör. 24 saat) veya sabit deneme sayısı sonrası olayı "inceleme gerekiyor" olarak işaretleyin ki insan tekrar oynatmayı kararlaştırabilsin.

Hızlı kontrol listesi ve sonraki adımlar

Webhook güvenilirliği çoğunlukla tekrar edilebilir alışkanlıklardır: hızlı kabul et, agresifçe çoğaltmayı engelle, dikkatle yeniden dene ve yeniden oynatma yolu bulundur.

Gelen (alıcı) hızlı kontroller

• İstek güvenle saklandıktan sonra hızlı bir 2xx döndürün (yavaş işleri asenkron yapın).
• Ne aldığınızı kanıtlamak ve sonra debug yapmak için olayı yeterince saklayın.
• Bir idempotency anahtarı zorunlu kılın (veya sağlayıcı+olay ID'den türetin) ve veritabanında zorlayın.
• Kötü imza veya geçersiz şema için 4xx, gerçek sunucu sorunları için 5xx kullanın.
• İşleme durumunu takip edin (alındı, işlendi, başarısız) ve son hata mesajını saklayın.

Giden (gönderici) hızlı kontroller

• Olay başına benzersiz bir olay ID atayın ve denemeler boyunca sabit tutun.
• Her isteği imzalayın ve zaman damgası ekleyin.
• Bir yeniden deneme politikası tanımlayın (geri çekilme, maksimum deneme ve durma kuralı) ve buna uyun.
• Uç nokta bazında durum tutun: son başarı, son başarısızlık, ardışık başarısızlıklar, bir sonraki deneme zamanı.
• Her denemeyi destek ve denetim için yeterli ayrıntıyla kaydedin.

Operasyon için, önden neyi yeniden oynatacağınızı (tek olay, zaman aralığına göre toplu, veya her ikisi), kimin yapabileceğini ve dead-letter inceleme rutinini belirleyin.

Eğer bu parçaları her şeyi elle yazmadan inşa etmek istiyorsanız, AppMaster gibi bir no-code platformu pratik bir çözüm olabilir: webhook inbox/outbox tablolarını PostgreSQL'de modelleyebilir, İş Süreçleri Editörü ile yeniden deneme ve yeniden oynatma akışlarını uygulayabilir ve partnerler dalgalanırken başarısız olayları arayıp yeniden çalıştırmak için dahili bir yönetim paneli yayınlayabilirsiniz.