Yinelenen Sipariş Oluşturmadan API Yeniden Denemesi

Basit yeniden denemelerin temel sorunu

Kısa yanıt şudur: ilk çağrıdan önce kararlı bir istek tanımlayıcısı ekleyin, yerel bir idempotency kaydı tutun, yeniden deneme sayısını sınırlayın, her deneme arasında geri çekilme uygulayın ve hâlâ çözümlenmemiş olayları insan inceleme kuyruğuna yönlendirin. Bu sıra, satıcı API'leri belirsiz yanıtlar döndürdüğünde bile yinelenen sipariş riskini azaltır. Makalenin geri kalanı her adımı ve kalıbın gerçek sınırlarını açıklar.

Bir satıcı API çağrısı aktarım sırasında başarısız olduğunda sisteminiz ikili bir seçimle karşılaşır: vazgeçmek ya da yeniden denemek. Vazgeçmek iş kaydında boşluk bırakır. Önlem almadan yeniden denemek ise aynı işlem için 2 sipariş, 2 lisans koltuğu veya 2 yenileme ücreti oluşturabilir.

Temel neden belirsizliktir. Zaman aşımı veya ağ hatası, bağlantı kesilmeden önce satıcının isteği işleyip işlemediğini söylemez. Sisteminizin bunu varsayması ve buna göre davranması gerekir.

Kararlı istek tanımlayıcıları

İlk güvence, her giden isteğe göndermeden önce eklediğiniz kararlı ve benzersiz bir tanımlayıcıdır. Çağrı başarısız olur ve yeniden denerseniz, aynı tanımlayıcıyı gönderirsiniz. Satıcı sistemi — idempotency'yi destekliyorsa — tanımlayıcıyı tanır ve isteği yeniden işlemek yerine orijinal sonucu döndürür.

İyi bir istek tanımlayıcısının temel özellikleri:

İlk denemeden önce, yalnızca bir kez oluşturulur
HTTP çağrısına değil, iş olayına bağlıdır
Yeniden denemelerin aynı değeri kullanması için kalıcı olarak saklanır
Satıcının belirlediği bir zaman penceresine göre kapsamlandırılır

Kararlı bir tanımlayıcı olmadan her yeniden deneme yeni bir istek gibi görünür. Tanımlayıcı olduğunda satıcı kendi tarafında yinelenenleri ayıklayabilir.

Sizin tarafınızdaki idempotency kayıtları

Autodesk, Microsoft ve Adobe ekosistemlerinde idempotency desteği uç noktalara göre farklılık gösterir. Bazı uç noktalar istemci tarafından sağlanan bir anahtara uyar; diğerleri önceki çağrının başarılı olup olmadığını doğrulamak için yeterli durum bilgisi sunmaz. Yalnızca satıcı davranışına güvenemezsiniz.

Entegrasyon katmanınız, her giden istek için kendi idempotency kaydını tutmalıdır. Bu kayıt; istek tanımlayıcısını, yük karmasını, deneme sayısını, son yanıt kodunu ve çözüm durumunu içerir. Her yeniden denemeden önce sisteminiz kaydı kontrol eder. Tamamlanmış bir durum zaten kayıtlıysa yeniden deneme atlanır.

Bu yerel kayıt, operasyon ekiplerine net bir denetim izi de sağlar. "O yenileme gerçekleşti mi?" diye soran bir satış lideri, e-posta onaylarına dayalı tahmin yerine kayıttan doğrudan yanıt alır.

Yeniden deneme pencereleri ve geri çekilme

Her başarısızlık hemen yeniden denemeyi gerektirmez. Satıcı API'sinden gelen hız sınırı yanıtı, sistemin sağlıklı ama meşgul olduğu anlamına gelir; milisaniyeler içinde yeniden denemek sorunu kötüleştirir. Sunucu hatası, saniyeler içinde geçen geçici bir arızaya ya da saatler süren derin bir kesintiye işaret edebilir.

Pratik bir yeniden deneme stratejisi 3 unsuru birleştirir:

Üstel geri çekilme — her yeniden deneme bir öncekinden daha uzun bekler, satıcı uç noktasındaki baskıyı azaltır
Jitter — küçük bir rastgele gecikme, eş zamanlı isteklerden gelen yeniden denemeleri yayarak hepsinin aynı anda satıcıya ulaşmasını engeller
Sabit yeniden deneme sınırı — belirlenen deneme sayısından sonra sistem durur ve olayı insan inceleme kuyruğuna yönlendirir

Yeniden deneme penceresi, satıcının idempotency anahtarı süre sonu içinde kalmalıdır. Anahtarınız son yeniden denemeden önce sona ererse yeni bir anahtar ve yeni bir yineleme kontrolü gerekir.

Hız sınırı yönetimi

Hız sınırları, satıcı API'lerinde bir hata durumu değil, normal bir işletim koşuludur. Entegrasyonunuz, sabit aralıklarla yeniden deneme göndermek yerine satıcının döndürdüğü hız sınırı başlıklarını okumalı ve bir sonraki denemeyi buna göre planlamalıdır.

Bir teklif, lisans etkinleştirme ve yenileme aynı anda kuyruktayken öncelik sırası önem taşır. Bugün sona eren yenilemeler yeni tekliflerin önüne geçer. Tüm istekleri eşit aciliyetle işleyen bir entegrasyon katmanı, hız sınırı bütçesini düşük öncelikli işlere harcayarak en önemli çağrıları geciktirir.

Apivom Atlas, bir API entegrasyon ağ geçididir. Satıcı uç noktalarına yönelik giden çağrıları yönetmek için tek bir yer sağlar; bu sayede yeniden deneme kuralları, geri çekilme ayarları ve öncelik mantığı, satıcı başına yazılmış betiklere dağılmak yerine tek bir konumda yapılandırılabilir.

Gözlemlenebilir durum izleri

Arka planda sessizce çalışan yeniden deneme mantığı farklı bir sorun yaratır: kimse ne olduğunu bilmez. Operasyon liderlerinin "O Microsoft siparişi hâlâ beklemede mi?" veya "Adobe yenilemesi gece yeniden denendi mi?" gibi sorulara yanıt vermesi gerekir.

Gözlemlenebilir bir durum izi, bir istek için her durum geçişini kaydeder:

Durum	Anlam
Beklemede	İstek oluşturuldu, henüz gönderilmedi
Denendi	Gönderildi, yanıt bekleniyor
Hız sınırına takıldı	Satıcı beklememizi istedi
Yeniden deneniyor	Geri çekilme zamanlayıcısı çalışıyor
Onaylandı	Satıcı başarı yanıtı döndürdü
Başarısız	Yeniden deneme sınırına ulaşıldı, incelemeye yönlendirildi

Bu iz, yalnızca geliştiriciler tarafından değil operasyon personeli tarafından da okunabilir olmalıdır. Durum dili bir geliştirici yorumu gerektiriyorsa iz görevini yerine getirmiyor demektir.

Kalıbın sınırları

Yeniden deneme kalıpları, belirsiz ağ çağrılarının mekanik sorununu çözer. Her şeyi çözmez.

Belirsiz iş kuralları kapsam dışındadır. Ekibiniz başarısız bir yenilemenin otomatik olarak yeniden denenmesi mi yoksa bir satış temsilcisinin incelemesini mi beklemesi gerektiği konusunda anlaşmamışsa hiçbir yeniden deneme yapılandırması bu kararı sizin yerinize vermez. Kalıp kuralı uygular; tanımlamaz.

Zayıf kaynak verisi, yeniden denemenin düzeltemeyeceği hatalara yol açar. Eksik müşteri tanımlayıcısı içeren bir teklif, ilk denemede ve sonraki her denemede başarısız olur. Entegrasyon katmanı yeniden deneme sınırından sonra doğru biçimde durur ve olayı incelemeye yönlendirir; ancak temel veri sorunu yine de bir insanın müdahalesini gerektirir.

Satıcı tarafı belirsizliği, bazı ekosistemlerde gerçek bir kısıttır. Satıcı API'si önceki çağrının işlenip işlenmediğini doğrulamak için yeterli durum bilgisi döndürmediğinde, yerel idempotency kaydınız yalnızca sisteminizin bildiklerini yansıtabilir. Satıcı isteği işlemiş ancak belirsiz bir yanıt döndürmüşse, bir sonraki otomatik yeniden deneme değil insan incelemesi en güvenli çözüm yoludur.

Apivom Atlas bir API entegrasyon ağ geçididir. Yeniden deneme kuralları yine de net iş kararları, güvenilir kaynak verisi ve yeterli durum bilgisi sunan satıcı yanıtları gerektirir. Ağ geçidi kalıbı tutarlı biçimde uygulamanız için size tek bir yer sunar; bu 3 alandaki eksiklikleri telafi edemez.

Kalıbı bir araya getirmek

Güvenilir bir yeniden deneme tasarımı net bir sıra izler. İlk çağrıdan önce kararlı bir tanımlayıcı oluşturun. Yerel olarak bir idempotency kaydı saklayın. İsteği tanımlayıcı eklenmiş şekilde gönderin. Başarısızlık durumunda, yeniden deneme kararı vermeden önce hatayı sınıflandırın. Jitter ile üstel geri çekilme uygulayın. Her yeniden denemeden önce idempotency kaydını kontrol edin. Yeniden deneme sınırında durun ve çözümlenmemiş olayları inceleme kuyruğuna yönlendirin. Her durum geçişini operasyon personelinin okuyabileceği bir izde kaydedin.

Bu sıra, satıcı API'leri öngörülemeyen biçimde davrandığında bile iş kaydının temiz kalmasına yardımcı olur. Entegrasyonu aynı zamanda denetlenebilir kılar: her sipariş, teklif, lisans veya yenilemenin ne denendiğini ve neyin çözüldüğünü gösteren belgelenmiş bir geçmişi olur.

Kalıbı birden fazla satıcı uç noktasında tutarlı biçimde uygulamak disiplin gerektirir. Her ekosistem — Autodesk, Microsoft, Adobe — kendine özgü hız sınırı davranışına, idempotency desteğine ve hata yanıtı biçimine sahiptir. Kalıbı tek bir yerde uygulayan tek bir entegrasyon katmanı, satıcı başına yazılan özel yeniden deneme mantığına kıyasla bakım yükünü azaltır.

Apivom Atlas hakkında bilgi almak için https://apivom.com/products/atlas adresini inceleyebilirsiniz.