IOSOR

IOSOR Rehber

Gelen SMS webhook’ları: yeniden deneme, olay sırası ve alımda idempotency

B2B alım yolu rehberi: gelen SMS webhook’ları nasıl yeniden dener, olay sırası neden garanti değildir ve idempotent handler’lar ön ödemeli ops ile destek makrolarını nasıl korur.

Giden SMS panelleri alır. Gelen taraf STOP, HELP ve müşteri yanıtlarının gerçekten indiği yerdir — ve saf handler’ların yinelenen ticket, çift cüzdan yan etkisi ve “STOP hiç gelmedi” uyumluluk hayaletleri ürettiği yerdir. Alım yolunuz sırayla exactly-once teslim varsayıyorsa ilk gerçek kesintide kırılırsınız.

IOSOR gelen mesajlaşmayı gidenle aynı white-label ön ödemeli yüzeyde paketler: doğrulanabilir olaylar, marka-güvenli yükler, yanıt fırtınasını uzlaştırmak için yabancı ops portalında yaşama zorunluluğu yok.

Webhook’lar neden yeniden dener

Çoğu platformda gelen webhook’lar yeniden denemeli at-least-once teslim vaat eder; büyülü exactly-once sıkı sıra değil.

  • Aynı mantıksal olayın yinelenen POST’ları
  • Zaman aşımı sonrası geç gelişler
  • Başka bir olay türüne göre ara sıra sıra dışı teslimler

Ürün UX’i, sizin mağazanız belirleyici birleştirme uygularsa yine sıralı hissedilebilir — hat hiç sarsılmaz diye umarak değil.

Tasarlamanız gereken üç hata modu

Failure mode What happens What breaks if you ignore it
Duplicate delivery Same event ID arrives 2+ times Double-counted replies, doubled STOP, duplicate threads
Out-of-order events A later-timestamped event arrives first A delivered status regresses to sent
Partial/ambiguous failure You processed but the ack was lost The platform retries work you already did

Idempotency: üçünü birden düzelten özellik

Gelen taraf para ve ops yan etkilerinden muaf değildir:

  • Otomatik yanıtlar ön ödemeli cüzdanı borçlandırabilir
  • STOP işleme gelecekteki pazarlama gönderimlerini bastırmalıdır
  • Ticket açan destek makroları üç POST için üç ticket açmamalıdır

Idempotent alım handler kontrol listesi:

Olay sırası: neden “last write wins” tehlikeli

Yaygın yanlış varsayımlar:

  1. STOP bir sonraki pazarlama gönderiminden önce gelir (yarış vardır)
  2. Giden DLR gelen yanıttan önce gelir (bağımsız yollar)
  3. Kalıcı olay anahtarı olmadan “ilk POST kazanır”

Kalıcı bir event / message id ile alım defteri kurun. İş kurallarını o defterde durum geçişleri olarak uygulayın; “her HTTP 200 yolunda yan etki çalıştır” olarak değil.

Kırmızı bayraklar

  • “Hiç yeniden denemeyiz” (uyumluluk olaylarını düşürürsünüz)
  • Event id yok — yalnızca zaman damgaları
  • Katı küresel sıra varsayan belgeler
  • Cüzdan izi olmayan otomatik yanıt fırtınaları
  • Geleni yeniden oynatmak için üçüncü taraf portal isteyen ops

IOSOR ile başlayın

Geçen haftanın inbound webhook günlüklerini çekin ve birden fazla gelen olay kimliklerini sayın. Bir kopyayı ve sırasız bir çifti (önce failed, sonra delivered) oynatın. Alıcı bir etki tutar: bir gelen kutusu satırı, bir STOP yazımı, bir cüzdan dokunuşu. STOP’u geri alan last-write-wins düşürür. Bu alımda eşgüçlülük ve yeniden deneme sırasıdır, imza doğrulama veya kuyruktan önce geçit kilidi değil.

IOSOR özeti

Inbound webhook’lar yeniden dener. Alımda eşgüçlülük tek güvenli yanıttır; sıra söz değildir.

Yapın: olaya anahtar verin, ikizi yok sayın. Yapmayın: STOP’ta last-write-wins veya aynı olayı iki kez düşmeyin.

Bu rehber yardımcı oldu mu?

İlgili rehberler