Webhook'lar vs Sorgulama: doğru entegrasyon yaklaşımını seçmek

Verileri senkronlarken neyi çözmeye çalışıyoruz?

Senkronizasyon kulağa “güncellemeleri hızlı göstermek” gibi gelebilir, ama gerçek iş daha zordur: mesajlar geç, yinelenmiş veya eksik olsa bile iki sistemin neyin doğru olduğunda anlaşmasını sağlamak.

Webhook'lar ile sorgulama (polling) arasındaki fark, bir şeyin değiştiğini nasıl öğrendiğinizdir.

Webhook push (itme) modelidir. Sistem A bir olay olduğunda (örneğin “payment_succeeded”) endpoint’inizi çağırır. Polling pull (çekme) modelidir: sisteminiz belli aralıklarla Sistem A'ya “son seferden beri yeni bir şey var mı?” diye sorar.

Sistemleri senkron tutmak genellikle hem olayları hem de durumu izlemeyi gerektirir. Olaylar ne olduğunu söyler. Durum bir kaydın şu an nasıl göründüğünü gösterir. Zamanlama önemlidir çünkü entegrasyonlar nadiren mükemmel sırada çalışır. Bir “güncellendi” olayı “oluşturuldu” olayından önce gelebilir, iki kez gelebilir veya hiç gelmeyebilir.

Amaç taze veri değil, doğru veridir. “Doğru”, değişiklikleri kaçırmamanız, aynı değişikliği iki kere uygulamamanız, kesintiden sonra elle temizleme yapmadan kurtarabilmeniz ve neyi ne zaman işlediğinizi kanıtlayabilmeniz demektir.

Pratik bir örnek: ödeme sağlayıcınız “payment_succeeded” gibi bir webhook gönderir. Uygulamanız bir sipariş oluşturup onu ödenmiş olarak işaretler. Eğer webhook endpoint’iniz kısa süreliğine kapalıysa bu olayı hiç görmeyebilirsiniz. “Dün’den beri güncellenenleri” soran bir polling işi ise boşluğu giderip sipariş durumunu düzeltebilir.

Gerçek dünyadaki çoğu entegrasyon her iki yöntemi de kullanır: hız için webhook'lar, geri doldurma ve doğrulama için polling. Yöntemden daha önemli olan etrafındaki güvenlik önlemleridir.

Gecikme ve tazelik: güncellemeler gerçekten ne kadar hızlı gelir?

İnsanlar webhook'lar vs polling karşılaştırması yaparken genelde tek bir şeye odaklanır: uygulamanızın bir değişikliği ne kadar çabuk fark ettiği. Bu tazelik sadece hoş bir şey değil. Destek taleplerini, çift işi ve kullanıcıların gördüklerine duydukları güveni etkiler.

Polling doğal olarak gecikme içerir çünkü sadece belirlenen aralıkta sorarsınız. Eğer her 5 dakikada bir poll yapıyorsanız, bir güncelleme birkaç saniyeden neredeyse 5 dakikaya kadar gecikebilir; buna API yanıt süresi de eklenir. Daha sık poll yapmak tazeliği artırır, fakat API çağrılarını, maliyeti ve hız sınırlarına takılma ihtimalini yükseltir.

Webhook'lar olay oluştukça sağlayıcı bunları iteceği için neredeyse gerçek zamanlı hissi verebilir. Ama bunlar anlık veya garantili değildir. Sağlayıcılar olayları paketleyebilir, daha sonra yeniden deneyecek veya teslimatı duraklatabilir. Sizin sisteminiz de gecikme ekler (kuyruk birikimleri, veritabanı kilitleri, dağıtımlar). Daha doğru beklenti: sağlıklı olduğunda hızlı, sorun çıktığında ise nihai tutarlılık (eventual consistency).

Trafik şekli önemlidir. Polling sabit, öngörülebilir yük verir. Webhook'lar patlamalıdır: yoğun bir saat içinde dakika başına yüzlerce olay gelebilir, sonra uzun süre sessizlik olabilir. Webhook kabul ediyorsanız, dalgalanmaları göz önüne alın ve olayları işlemenizi kontrollü bir tempoya sokacak şekilde kuyruğa alın.

Herhangi bir tasarıma başlamadan önce hedef tazelik penceresini seçin:

• Saniyeler: kullanıcıya yönelik bildirimler, sohbet, ödeme durumu
• Dakikalar: destek araçları, yönetici görünümleri, hafif raporlama
• Saatler: gececil uzlaşma, düşük öncelikli analizler

Eğer satış ekibinin yeni lead'lerin 1 dakika içinde görünmesi gerekiyorsa, webhook'lar bunu sağlar. Buna ek güvenlik için birkaç saatte bir çalışan bir “safety poll” kaçırılan olayları yakalayıp son durumu teyit edebilir.

Prodüksiyonda gerçekten göreceğiniz başarısızlık modları

Çoğu entegrasyon sıkıcı, tekrarlanabilir şekillerde başarısız olur. Şaşırtıcı olan bir şey bozulması değil, sessizce bozulmasıdır. Hız tartışması kolaydır; güvenilirlik asıl işin olduğu yerdir.

Polling hataları genellikle “güncellemeyi görmedik” şeklinde görünür, kod doğru olsa bile. Zaman aşımı bir isteği yarıda kesebilir. Sadece HTTP 200'e bakıp gövdeyi doğrulamazsanız kısmi yanıtlar kaçabilir. Paginasyon değişiklikleri sık görülür: bir API sıralamayı değiştirir, sayfa kurallarını değiştirir veya sayfa numaralarından cursor tabanlıya geçer ve öğeleri atlar ya da yeniden okursunuz. Bir diğer klasik hata, “updated_since” filtresini yerel saatinizle kullanmak ve saat kayması olduğunda veya sağlayıcı farklı bir zaman damgası alanı kullandığında güncellemeleri kaçırmaktır.

Webhook'lar farklı şekilde başarısız olur. Teslim genelde “en az bir kez” şeklindedir; sağlayıcılar ağ hatalarında yeniden dener ve siz tekrar eden olaylar görürsünüz. Endpoint’iniz 10 dakika kapalıysa, eski olayların bir patlamasını daha sonra alabilirsiniz. İmza doğrulama sorunları da sık görülür: bir gizli anahtar döndürülür, yanlış ham yükü doğruluyorsunuz ya da bir proxy başlıkları değiştiriyor ve bir anda geçerli olaylar geçersiz görünüyor.

Her iki yaklaşımda da ortak başarısızlık modu, çoğaltmalar ve sıra dışı teslimattır. Aynı olayı birden fazla kez alacağınızı, olayların geç geleceğini, sırasız geleceğini ve beklediğiniz alanları içermeyen payload'lar alabileceğinizi varsayın.

Neredeyse hiç zaman “tam olarak bir kez” elde edemezsiniz. “En az bir kez” olarak tasarlayın ve işleme güvenli olacak şekilde yapın. Bir idempotency anahtarı (olay ID'si veya sağlayıcı nesne versiyonu) saklayın, tekrarları görmezden gelin ve güncellemeleri yalnızca sakladığınızdan daha yeni ise uygulayın. Ayrıca ne aldığınızı ve onunla ne yaptığınızı kaydedin, böylece tahmin etmek yerine güvenle yeniden oynatabilirsiniz.

İstek sınırları ve maliyet: API kullanımını kontrol altında tutmak

İstek sınırları, webhook'lar vs polling teoriden bütçe ve güvenilirlik sorununa döndüğü yerdir. Her ekstra istek zaman ve para maliyeti getirir ve sağlayıcıyla ilişkinize zarar verebilir.

Polling kotaları hızla tüketir çünkü hiçbir şey değişmediğinde bile sorgulamak için ödeme yaparsınız. Durum, limitlerin kullanıcı veya token başına olması durumunda daha da kötüleşir: dakikada bir poll yapan 1.000 müşteri, her müşteri “iyi davranıyor” olsa bile saldırı gibi görünebilir. Polling ayrıca çağrıları çarpar (liste endpointleri, ardından her öğe için detay çekme), bu da beklenmedik şekilde tavanı vurmanıza yol açar.

Webhook'lar genelde API çağrılarını azaltır, ama patlama baskısı yaratır. Bir sağlayıcı kesinti, toplu içe aktarma veya ürün lansmanı sonrası binlerce olayı aynı anda gönderebilir. Bazıları sizi 429 ile sınırlayabilir, bazıları agresifçe yeniden dener ve bazıları endpoint’iniz yavaşsa olayları düşürebilir. Tarafta geriye basınç (backpressure) oluşturmanız gerekir: hızlıca kabul edin, işi kuyruğa alın ve güvenli bir hızda işleyin.

Doğruluğu kaybetmeden çağrıları azaltmak için uygulamada işe yarayan birkaç desene odaklanın:

• “Updated since” zaman damgaları veya değişim tokenleri kullanarak artımlı senkronizasyon
• Sunucu tarafı filtreleme (sadece ihtiyaç duyduğunuz olay türlerine abone olun)
• Okumaları ve yazmaları toplu yapmak (detayları parça parça çekmek, yazmayı toplu yapmak)
• Stabil referans verilerini önbelleğe almak (planlar, durum listeleri, kullanıcı profilleri)
• “Gerçek zamanlı” ile “raporlama” ihtiyaçlarını ayırmak (hızlı yol vs gece işleri)

Zirveler için önceden plan yapın. Kotalara saygılı, daha yavaş çalışan ve duraklatılıp devam ettirilebilen özel bir backfill modu tutun.

Doğru yaklaşımı seçmek: basit bir karar rehberi

Webhook'lar vs polling tercihi genelde şuna iner: hız mı lazım, yoksa satıcı güvenilir olmadığında bile güncellemeleri almak için basit, öngörülebilir bir yol mu lazım?

Polling, üçüncü taraf webhook sunmuyorsa veya iş akışınız gecikmeye dayanabiliyorsa genelde daha iyi bir varsayılan seçimdir. Ayrıca API açık bir “updated since” filtresi sağlıyorsa günlük veya saatlik bir senkronizasyon gerekiyorsa anlaşılması kolaydır.

Webhook'lar zamanın önemli olduğu durumlarda daha iyi bir varsayılandır: “yeni sipariş alındı”, “ödeme başarısız”, “ticket atandı” gibi. Boşa giden API çağrılarını azaltır ve işi hemen tetikleyebilir.

Doğruluğun önemli olduğu durumlarda her ikisini birden kullanmak pratik bir kuraldır. Webhook'lar size hızı verir, polling kaçırdıklarınızı temizler. Örneğin webhook'ları hızlı işleyin, ardından 15 dakikada bir (veya birkaç saatte bir) planlı bir poll çalıştırarak düşen olayları ve geçici kesintilerden kaynaklanan boşlukları yeniden doldurun.

Kısa rehber:

• Dakikalar seviyesinde gecikme uygunsa polling ile başlayın.
• Güncellemelerin saniyeler içinde görünmesi gerekiyorsa webhook ile başlayın.
• Sağlayıcı güvenilmezse veya olaylar kritikse webhook + polling planlayın.
• API çok kısıtlıysa webhook tercih edin, hafif polling ile destekleyin.
• Veri hacmi yüksekse sık tam poll'lardan kaçının.

Karar vermeden önce satıcıya birkaç soru sorun ve net cevap alın:

• Hangi olay türleri var ve bunlar eksiksiz mi (create, update, delete)?
• Webhook'ları yeniden denerler mi ve ne kadar süreyle?
• Olayları yeniden oynatabilir misiniz veya zaman aralığına göre olay geçmişi çekebilir misiniz?
• Webhook isteklerini imzalıyorlar mı, böylece doğruluğunu kontrol edebilirsiniz?
• Verimli polling için “updated since” sorgularını destekliyorlar mı?

Adım adım: doğru kalan bir senkronizasyon tasarlamak

“Doğru” bir senkronizasyon sadece “veri geliyor” demek değildir. Doğru kayıtlar eşleşir, en son değişiklik kazanır ve bir şey ters gittiğinde ne olduğunu kanıtlayabilirsiniz.

Test edilebilir ve izlenebilir bir planla başlayın:

1. Tanımlayın: hangi alanın gerçek kaynağı olduğunu ve kuralları. CRM müşteri adını sahiplensin ama faturalama aracı abonelik durumunu yönetsin gibi. “Yeterince taze”nin ne anlama geldiğini (örneğin “5 dakika içinde”) ve hangi hataların kabul edilebilir olduğunu belirleyin.
2. Stabil tanımlayıcılar seçin. Üçüncü tarafın benzersiz ID'sini kendi iç ID'nizin yanında saklayın. Anahtar olarak e-posta veya isim kullanmaktan kaçının (değişirler). Varsa bir versiyon veya “updated_at” zaman damgası saklayın, böylece daha yeni veriyi tespit edebilirsiniz.
3. İlk içe aktarıma, sonra artımlı güncellemelere plan yapın. İlk içe aktarmayı duraklatma ve kaldığı yerden devam ettirebilme checkpoint'leriyle ayrı bir iş olarak ele alın. Ondan sonra yalnızca değişiklikleri işleyin (olaylar, “since” sorguları veya her ikisi) ve “son başarılı senkron zamanı” gibi bir cursor kaydedin.
4. Silmeleri ve birleştirmeleri kasıtlı olarak yönetin. Silmeler kaydı silsin mi, arşivlesin mi yoksa pasif olarak işaretlesin mi karar verin. Birleştirmelerde hangi ID'nin kalacağına karar verin ve bir denetim izi saklayın.
5. İzleme sinyalleri belirleyin. Senkron gecikmesini, başarısız çağrıları ve takılı kuyrukları izleyin. Eşik aşıldığında uyarı verin; sadece bir şey çöktüğünde değil.

Bunu uygularken seçimlerinizi veri modelinizde görünür tutun: dış ID'ler, zaman damgaları, durum alanları ve senkron checkpoint'lerini saklayacak yer. Gerçek dünya karmaşıklaştığında bu yapı senkronun doğru kalmasını sağlar.

İdempotensi ve sıralama: güvenilir entegrasyonların özü

Webhook'lar vs polling entegrasyonlarını yeterince uzun inşa ederseniz, her seferinde bir kural ortaya çıkar: çiftler, yeniden denemeler ve sıra dışı güncellemeler göreceksiniz. Senkronizasyonunuz aynı mesajı güvenle yeniden işleyemiyorsa zaman içinde sapma oluşur.

İdempotensi “aynı girdi, aynı sonuç” demektir; iki kez gelse bile. Gelen her olayı “belki tekrar yoktur” diye ele alın ve handler'ınızı güvenli olacak şekilde tasarlayın. Yaygın bir desen: bir dedup anahtarı hesapla, daha önce işlenmiş mi diye kontrol et, sonra değişiklikleri uygula.

Dedup anahtarlarının dezavantajları ve avantajları vardır. Sağlayıcı bir olay ID'si verdiyse bu en iyisidir. Yoksa bir nesne versiyonu (artan revizyon gibi) kullanabilirsiniz. “10 dakika için tekrarları yoksay” gibi zaman damgası pencereleri geç kalan teslimatlar nedeniyle kırılgan olabilir.

Sıralama diğer yarıdır. Global sıralama nadirdir; bu yüzden nesne başına sıralamayı hedefleyin. Bir bilet, fatura veya müşteri gibi tek bir nesneye yapılan güncellemeleri yalnızca sakladığınız versiyondan daha yeni ise uygulayın. Versiyon yoksa açık bir kural ile son yazım kazanır (örneğin daha yeni updated_at kazanır) ve saat kayması kenar durumları yaratabileceğini kabul edin.

Yeniden kurtarmak ve yeniden oynatmak için yeterince veri saklayın:

• Nesne başına “son görülen” versiyon veya updated_at
• Polling işler için son işlenen cursor veya checkpoint
• İşlenmiş olay ID'lerinin tablosu (çok hızlı büyürse saklama kuralı ile)
• Kısa süre için ham payload'ı saklamak, böylece düzeltmeleri yeniden çalıştırabilirsiniz

Örnek: Stripe ödeme webhook'u iki kez gelir, sonra “paid” güncellemesi “created” olayından önce gelir. Eğer faturanın en son durum versiyonunu saklıyor ve daha eski güncellemeleri yok sayıyorsanız doğru sonuca ulaşırsınız.

Sessiz veri sapmasını önleyen yeniden deneme ve yeniden oynatma desenleri

Çoğu entegrasyon sessizce başarısız olur. Bir webhook geç gelir, bir polling işi kotaya takılır veya uygulamanız kaydederken zaman aşımı yaşar. Yeniden deneme ve yeniden oynatma olmadan sistemler yavaşça ayrışır, ta ki bir müşteri şikayet edene kadar.

Webhook yeniden denemeleri: hızlı kabul edin, güvenle işleyin

Sağlayıcılar genelde başarılı HTTP kodu dönülmediğinde yeniden dener. Webhook isteğini ağır işi yapacağınız yer olarak değil, teslimat bildirimi olarak ele alın.

Pratik bir webhook deseni:

• Temel doğrulamadan (imza, şema, zaman damgası) sonra hızlıca 2xx ile cevap verin.
• Olayı benzersiz bir ID ile saklayın ve beklemede (pending) işaretleyin.
• Bir worker ile asenkron olarak işleyin ve deneme sayısını takip edin.
• Geçici hatalarda daha sonra yeniden deneyin. Kalıcı hatalarda durun ve uyarı verin.
• Kötü veri için 4xx, gerçek sunucu sıkıntısı için 5xx kullanın.

Bu, sık yapılan bir tuzaktan kaçınır: “webhook alındı” demenin “veri senkron” olduğu anlamına geldiğini düşünmek.

Polling yeniden denemeleri: API'ye nazik davranın

Polling farklı başarısız olur. Risk, kısa bir kesintiden sonra yankılanan bir sağanak yeniden denemedir ve bu hız sınırlarını daha da kötüleştirir. Üstel geri çekilme (exponential backoff) ve jitter kullanın, ve her şeyi yeniden taramamak için bir “since” cursor tutun.

Şimdi işleyemediğiniz bir şeyi bir dead-letter kuyruğuna (veya tabloya) koyun; nedeniyle birlikte. Bu, nelerin kaybolduğunu tahmin etmek yerine inceleyip düzeltip yeniden çalıştırmak için güvenli bir yer sağlar.

Yeniden oynatma, kaçırılan olaylardan sonra iyileşme yoludur. Basit bir yeniden oynatma stratejisi:

• Bir zaman penceresi seçin (örneğin son 24 saat) veya etkilenen kayıt setini seçin.
• Sağlayıcıdan güncel durumu yeniden çekin.
• Güncellemeleri idempotent olarak yeniden uygulayın ve uyumsuzlukları düzeltin.
• Ne değiştiğini ve nedenini kaydedin.

Örnek: faturalama sağlayıcınız “invoice.paid” gönderir, ama veritabanınız 30 saniye boyunca kilitliydi. Olayı dead-letter'a koyarsınız, sonra faturayı ve ödeme durumunu yeniden çekip kayıtları güncelleyerek yeniden oynatırsınız.

Yaygın hatalar ve nasıl önlenirler

Çoğu senkron hata “büyük mimari” değil, küçük varsayımlardır. Bunlar sessiz sapma, çoğaltılmış kayıtlar veya kaçırılmış güncellemeler haline gelir.

Sürekli görülen birkaç hata:

• İncremental filtreler olmadan çok sık polling yapmak. Bir cursor (updated_at, olay ID'si, sayfa tokeni) takip edin ve yalnızca son başarılı çalışmadan beri değişiklikleri sorgulayın.
• Webhook'ları garantili teslimat gibi kabul etmek. Kaçırılanları yeniden kontrol edecek (örneğin son 24–72 saat) bir backfill işi tutun.
• Çoğaltmaları görmezden gelmek. Her yazmayı idempotent yapın. Sağlayıcı olay ID'sini (veya stabil dış ID) saklayın ve aynı değişikliği iki kere uygulamayı reddedin.
• Webhook çağrılarını doğrulamadan kabul etmek. Sağlayıcının sunduğu imza tokenini veya doğrulama yöntemini kullanın.
• Senkron sağlık durumunu görmezden gelmek. Gecikmeyi, bekleyen iş sayısını, son başarılı çalıştırma zamanını ve hata oranlarını takip edin. Gecikme bir eşiği geçtiğinde uyarı verin.

Birçok “webhook'lar vs polling” tartışması konunun özünü kaçırır: her iki yöntemin etrafındaki güvenlik önlemleri güvenilirliği sağlar. Bir ödeme webhook'u iki kez gelebilir veya geç gelebilir. Sisteminiz webhook üzerinden doğrudan kayıt oluşturup idempotensi içermiyorsa, bir müşteriye iki kez mesaj gönderebilir veya iki kez ücretlendirebilirsiniz.

Sağlıklı bir entegrasyon için hızlı kontrol listesi

Günlük kontroller webhook, polling veya her ikisini kullansanız da benzer görünür. Verinin taze olup olmadığını, hataların birikip birikmediğini ve temiz şekilde kurtarılıp kurtarılamayacağını bilmek istersiniz.

Kısa bir kontrol listesi (birkaç dakikada çalıştırılabilir):

• Tazelik: “son olay alındı” veya “son poll tamamlandı”yı beklenen gecikmeyle karşılaştırın.
• Hatalar: artan yeniden deneme sayıları veya uzun süredir ilerlemeyen işler arayın. Hata sayılarını “son başarı” zaman damgası ile eşleştirin.
• Kotalar: kaç API çağrısı kullandığınız ve kalan hakkınızı kontrol edin. Limitlere yakınsanız polling'i yavaşlatın ve istekleri toplu yapın.
• Doğruluk: sistemler arası toplamları örnekleyin (örneğin “bugün siparişler”) ve birkaç güncel kaydı kontrol edin.
• Kurtarma hazırlığı: son pencereyi güvenle yeniden işleyebildiğinizi ve çoğaltma ya da kaçırma olmadan tekrar çalıştırabildiğinizi doğrulayın.

Yararlı bir alışkanlık, kontrol altında bilinen yoğun bir dönemi periyodik olarak yeniden oynatmak ve sonuçların üretimle eşleştiğini doğrulamaktır.

Örnek: gerçekçi bir iş akışı için webhook ve polling karışımı

Küçük bir SaaS ekibini düşünün: CRM (kişiler ve fırsatlar), Stripe ödemeleri (ücretler ve iadeler) ve bir destek aracı (ticket durumu) olmak üzere üç sistemin senkron kalması gerekiyor.

Hız gerektiren her şey için webhook-öncelikli bir kurulum kullanıyorlar. CRM olayları müşteri kaydını günceller ve dahili görevleri tetikler. Stripe webhook'ları faturaları oluşturur, ödeme sonrası özellikleri açar ve başarısız ödemelerde hesapları gecikmeye düşürür. Destek aracı için webhook varsa kullanıyorlar, ama bilet durumları toplu değişebildiği için ayrıca zamanlanmış bir poll da tutuyorlar.

Polling'i ana motor olarak değil, güvenlik ağı olarak kullanıyorlar. Her gece, 24 saatin sonundaki değişiklikleri çeken bir uzlaşma işi çalıştırıyor ve bunları uygulamada saklananla karşılaştırıyor.

Sonra gerçek bir kesinti oluyor: dağıtım sırasında webhook endpoint'leri 20 dakika boyunca kapalı kalıyor.

• CRM ve Stripe teslimatları bir süre yeniden deniyor.
• Bazı olaylar geç geliyor, bazıları sıradan çıkıyor ve bazıları süresi doluyor olabilir.
• Uzlaşma poll'ü bir boşluk tespit ediyor (kaybolan olay ID'leri veya uyuşmayan toplamlar) ve eksik değişiklikleri geri dolduruyor.

Ne kaydediyorlar: gelen olay ID'si, sağlayıcı zaman damgası, iç kayıt ID'si ve nihai sonuç (oluşturuldu, güncellendi, yok sayıldı). Ne tetikleyip uyarılıyor: tekrarlayan webhook hataları, yeniden denemelerde ani artış veya uzlaşmanın beklenenden fazla eksik güncelleme bulması.

Sonraki adımlar: uygulayın, izleyin ve yineleyin

Çoğu ekip için pratik bir varsayılan basittir: aciliyet için webhook'ları kullanın ve doldurma için küçük bir polling işi tutun. Webhook'lar değişiklikleri size hızlı getirir. Polling ise kesintiler, yanlış yapılandırılmış abonelikler veya zaman zaman olay düşüren bir sağlayıcı nedeniyle kaçırdıklarınızı yakalar.

Hızı önce yapmadan önce senkronun doğru olduğundan emin olun. Gelen her değişikliği birden fazla kez güvenle uygulayabileceğiniz şekilde ele alın.

İlk üç eylem:

• Sağlayıcının olaylarını ve alanlarını kendi iç modelinize eşleyin; “silme”, “iade” veya “durum değişimi”nin sizin için ne anlama geldiğini belirleyin.
• Baştan idempotensi tasarlayın: dış olay ID'si veya versiyon saklayın ve her güncellemenin tekrar çalıştırılabilir ve çoğaltmasız olmasını sağlayın.
• Kasıtlı olarak yeniden oynatma ekleyin: “son görülen” cursor veya zaman-penceresi poll'u tutun ve bir şey ters görünürse bir aralığı yeniden çalıştırmak için yönetici aracı yapın.

Çalıştıktan sonra izleme, onu ayakta tutan şeydir. Webhook teslim oranını, neden başarısız olduklarına göre hataları (zaman aşımı, 4xx, 5xx) ve uzlaşma poll'ünüzün ne kadar geride olduğunu izleyin. “Hiç olay alınmadı”yı da “çok fazla olay alındı”yı da uyarı konusuna ekleyin.

Eğer sıfırdan tam bir backend yazmak istemiyorsanız, AppMaster (appmaster.io) kodsuz bir seçenek sunar: veri modelleyebilir, webhook endpointleri oluşturabilir ve yeniden deneme/yeniden oynatma akışlarını görsel araçlarla tasarlayabilirsiniz; aynı zamanda dağıtım için gerçek kaynak kodu üretebilir.