Gönderim API Entegrasyonu: Hata Yönetimi ve Yeniden Deneme
Uygulamanız sipariş onayını gönderim servisine iletiyor. Çoğu zaman sorunsuz çalışıyor. Ama servis bir dakikalığına yanıt vermediğinde ne oluyor? Bazı uygulamalarda ileti sessizce kayboluyor, bazılarında müşteriye üç kez gidiyor.
Bu yazı, gönderim servisi entegrasyonunun dayanıklılığını ele alıyor.
Doğrudan Çağrının Sorunu
- Kullanıcı işlemi tamamlar.
- Kod gönderim servisini çağırır.
- Yanıt beklenir.
Üçüncü adım kullanıcıyı doğrudan etkiler: e-posta gönderimini istek içinde beklemek, gönderim servisi yavaşladığında sipariş sayfasının da yavaşlamasına yol açar — dış bir servisin sorunu sizin uygulamanızın sorunu hâline gelir.
Servis tamamen çökerse sipariş bile tamamlanamayabilir.
Bu, kabul edilemez bir bağımlılıktır.
E-posta gönderimi sipariş almanın önkoşulu olmamalıdır.
Kuyruğa Almak
- İstek anında kuyruğa yazılır.
- Arka plan işçisi gönderir.
- Kullanıcı beklemez.
İkinci madde tüm dayanıklılığı sağlar: gönderimi arka plana almak, servis geçici olarak erişilemez olduğunda iletilerin kaybolmak yerine kuyrukta beklemesini ve servis döndüğünde gönderilmesini sağlar.
Kuyruk basit bir veritabanı tablosu olabilir.
Karmaşık bir altyapı gerekmez.
Üçüncü madde ise kullanıcı deneyimini korur.
Hata Türlerini Ayırmak
| Hata | Yapılacak |
|---|---|
| Ağ zaman aşımı | Tekrar dene |
| Sunucu hatası | Tekrar dene |
| Geçersiz adres | Tekrar deneme |
| Kimlik doğrulama hatası | Tekrar deneme, uyar |
Üçüncü ve dördüncü satırlar kritik ayrımlardır: geçersiz bir adres veya yanlış bir anahtar yüzünden başarısız olan bir gönderimi tekrar tekrar denemek hiçbir işe yaramaz — yalnızca kuyruğu tıkar ve gerçek iletilerin gecikmesine yol açar.
Kalıcı hatalar hemen işaretlenmelidir.
Dördüncü satır ayrıca uyarı gerektirir.
Anahtar geçersizse tüm gönderim durmuştur.
Yeniden Deneme Aralığı
- Hemen tekrar denemek işe yaramaz.
- Aralık kademeli artmalı.
- Rastgelelik eklenmeli.
Üçüncü madde toplu başarısızlıklarda önemlidir: servis kesintisi sonrası binlerce ileti aynı anda tekrar denenirse servis yeniden çöker — bekleme sürelerine rastgele bir pay eklemek bu dalgayı dağıtır.
Bu ayrıntı sıkça atlanır.
İkinci madde ise geçici sorunlara zaman tanır.
Birkaç saniyeden başlayıp dakikalara çıkılır.
Çift Gönderimi Önlemek
- Yanıt kaybolabilir.
- İleti gitmiş olabilir.
- Benzersiz anahtar kullanılmalı.
İkinci madde tekrar denemenin riskini açıklar: zaman aşımına uğrayan bir istekte ileti gerçekte gönderilmiş olabilir — körü körüne tekrar denemek müşteriye aynı e-postayı iki kez göndermek demektir.
Üçüncü madde çözümü verir.
Her ileti için benzersiz bir anahtar gönderilir.
Servis aynı anahtarı ikinci kez işlemez.
Çoğu gönderim servisi bunu destekler.
Oran Sınırı
| Durum | Doğru davranış |
|---|---|
| Sınır aşıldı yanıtı | Belirtilen süre beklenir |
| Süre belirtilmemiş | Kademeli bekleme |
| Israrla denemek | Engellenme riski |
Üçüncü satır ciddi bir sonuç doğurabilir: oran sınırına takıldıktan sonra beklemeden denemeye devam etmek, hesabınızın geçici veya kalıcı olarak kısıtlanmasına yol açabilir — servis bunu kötüye kullanım olarak değerlendirir.
Birinci satır ise doğru davranıştır.
Servis genellikle ne kadar bekleneceğini bildirir.
Bu bilgi yanıt başlıklarında bulunur.
Gönderim Durumunu İzlemek
- Kabul edildi teslim edildi demek değildir.
- Sonraki olaylar takip edilmeli.
- Kayıt tutulmalı.
Birinci madde önemli bir yanılgıyı düzeltir: gönderim servisinin başarılı yanıt vermesi iletinin alıcıya ulaştığı anlamına gelmez — yalnızca kuyruğa alındığı anlamına gelir, teslimat sonucu dakikalar sonra belli olur.
Bu nedenle olay bildirimleri dinlenmelidir.
Teslim edilemedi bildirimleri işlenmelidir.
Üçüncü madde ise destek taleplerinde gerekir.
Yedek Sağlayıcı
- Tek sağlayıcı tek nokta arızasıdır.
- İkinci sağlayıcı tanımlanabilir.
- Kritik iletiler için değerlidir.
Üçüncü madde önceliği belirler: şifre sıfırlama ve doğrulama kodu gibi iletiler için yedek bir gönderim yolu bulundurmak, sağlayıcı kesintisinde kullanıcıların sisteme girememesini önler — pazarlama iletileri için bu gerekmez.
Yedek sağlayıcı için kimlik kayıtları da hazır olmalıdır.
Kesinti anında kayıt eklemek zaman alır.
Bu hazırlık önceden yapılmalıdır.
Test Ortamı
| Ortam | Davranış |
|---|---|
| Geliştirme | Hiç göndermez, kaydeder |
| Test | Yalnızca izinli adreslere |
| Üretim | Gerçek gönderim |
İkinci satır ciddi kazaları önler: test ortamında gerçek müşteri adreslerine gönderim yapılmasını engelleyen bir güvenlik kilidi, üretim verisi kopyalanmış bir test sisteminden binlerce kişiye yanlış e-posta gitmesini önler.
Bu kaza sanılandan sık yaşanır.
İzin listesi dışındaki adresler engellenmelidir.
Bu kilit yapılandırmayla değil kodla korunmalıdır.
Gönderim altyapınızın kesintisiz ve izlenebilir olması entegrasyonun temelidir; e-posta altyapı hizmeti ile gönderim akışınızı uçtan uca kurgulayabilirsiniz.
Sonuç
E-posta gönderimi asla kullanıcı isteğinin içinde beklenmemelidir: dış bir servisin sorunu sizin uygulamanızın sorunu hâline gelir. Kuyruğa alın, hata türlerini ayırın — geçersiz adres yüzünden başarısız olan bir gönderimi tekrar denemek yalnızca kuyruğu tıkar — benzersiz anahtarla çift gönderimi önleyin ve oran sınırına takıldığınızda bekleyin.
Sıkça Sorulan Sorular (SSS)
E-postayı neden kuyruğa almalıyım?
Gönderimi istek içinde beklemek, servis yavaşladığında sipariş sayfanızın da yavaşlamasına yol açar; servis çökerse işlem hiç tamamlanamayabilir. Kuyruk, iletilerin kaybolmak yerine beklemesini ve servis döndüğünde gönderilmesini sağlar.
Hangi hatalarda tekrar denemeliyim?
Ağ zaman aşımı ve sunucu hatası gibi geçici hatalarda. Geçersiz adres veya kimlik doğrulama hatası gibi kalıcı hatalarda tekrar denemek işe yaramaz; yalnızca kuyruğu tıkar ve gerçek iletilerin gecikmesine yol açar.
Tekrar denerken çift gönderim riski var mı?
Var. Zaman aşımına uğrayan bir istekte ileti gerçekte gönderilmiş olabilir; körü körüne tekrar denemek müşteriye aynı e-postayı iki kez göndermektir. Her ileti için benzersiz bir anahtar gönderin; servis aynı anahtarı ikinci kez işlemez.
Başarılı yanıt teslim edildi demek mi?
Hayır, yalnızca kuyruğa alındığı anlamına gelir. Teslimat sonucu dakikalar sonra belli olur. Bu yüzden olay bildirimlerini dinleyin ve teslim edilemedi bildirimlerini işleyin.
