Konuyu Açan
#1
Bir e-ticaret projesinde ödeme sağlayıcısının webhook’unu doğrudan sipariş güncelleyen endpoint’e bağlamak başlangıçta pratik görünüyor. Ama aynı olay tekrar gönderildiğinde ya da veritabanı kısa süreliğine yanıt vermediğinde, sipariş durumunu iki kez değiştirmek veya sağlayıcıdan gereksiz tekrarlar almak mümkün. İnternetten gelir getiren bir projede bu küçük görünen akış, destek yükünü de doğrudan etkiliyor.
Benim dikkat ettiğim üç nokta var:
Node.js tarafında bunu tek bir endpoint ve veritabanı kaydıyla mı çözdünüz, yoksa ayrı bir kuyruk/worker yapısı mı kullanıyorsunuz? Özellikle tekrar teslimat ve sıralama sorunlarını nasıl ele alıyorsunuz?
Benim dikkat ettiğim üç nokta var:
- İmzayı ham gövde üzerinden doğrulamak: JSON’u parse edip yeniden serileştirdikten sonra imza kontrol etmek sorun çıkarabilir. İmza doğrulamasında sağlayıcının beklediği ham request gövdesini kullanıyorum.
- Olayı idempotent işlemek: Her webhook olayının kimliğini veritabanında benzersiz tutmak, aynı olay tekrar geldiğinde ikinci kez işlem yapılmasını engelliyor. Yalnızca uygulama içi belleğe güvenmek süreç yeniden başlayınca koruma sağlamaz.
- Hızlı yanıt verip işi kuyruğa bırakmak: İmza ve temel doğrulama tamamlandıktan sonra olayı kalıcı biçimde kaydedip 2xx yanıtı dönmek, uzun süren e-posta veya stok işlemlerini webhook isteğinden ayırıyor. Kuyrukta başarısız işler için tekrar deneme ve gözlemleme de ayrıca gerekli.
Node.js tarafında bunu tek bir endpoint ve veritabanı kaydıyla mı çözdünüz, yoksa ayrı bir kuyruk/worker yapısı mı kullanıyorsunuz? Özellikle tekrar teslimat ve sıralama sorunlarını nasıl ele alıyorsunuz?