Takip API'si Ölçeklenebilirliği: Yoğun Sezon Hacmi, Hız Sınırları ve Toplu Kayıt İşlemleri Nasıl Yönetilir

Yoğun sezon için bir takip API'sini ölçeklendirmek amacıyla gönderi kaydını dayanıklı bir kuyruğun arkasına alın, tüm çalışanlar genelinde sağlayıcı limitlerini uygulayın, yalnızca belgelenmiş limitler dahilinde toplu işlem yapın ve takip güncellemelerini asenkron olarak işleyin. Kayıt aktarım kapasitesini, yeniden deneme trafiğini ve webhook işlemeyi ayrı kapasite sorunları olarak ele alın. Giden istekleri kontrol etmeden daha fazla çalışan eklemek, birikmiş işleri azaltmak yerine kısıtlamayı artırabilir.

Bir sipariş yönetim sistemini, depo platformunu veya e-ticaret arka ucunu bir takip hizmetine bağlayan mühendislik ekipleri için amaç yalnızca daha fazla istek göndermek değildir. Amaç, gönderileri belirli bir zaman aralığı içinde kaydetmek, trafik artışları sırasında güncellemeleri korumak ve yinelenen işler oluşturmadan hatalardan kurtulmaktır.

İş yükünü gönderiler, istekler ve güncellemeler etrafında boyutlandırın

Bir entegrasyonu boyutlandırmak için günlük gönderi hacmi yeterli değildir. Bir depo, takip numaralarının çoğunu kısa bir sevkiyat aralığında yayımlayabilirken durum güncellemeleri gün boyunca gelebilir. Bu iş yüklerini ayrı ayrı modelleyin.

• Kayıt gelişleri: İçe aktarmalar ve depodan gelen sevkiyat yoğunlukları dahil olmak üzere sisteminize saniye veya dakika başına giren yeni gönderi kayıtları.
• Giden API trafiği: Kayıt istekleri, sorgular, düzeltmeler, mutabakat çağrıları ve yeniden denemeler.
• Gelen güncelleme trafiği: Sağlayıcının desteklediği durumlarda webhook teslimatları ve yeniden teslimatlar.
• Alt sistem işleri: Her güncellemenin tetiklediği veritabanı yazma işlemleri, müşteri bildirimleri, analiz etkinlikleri ve sipariş durumu değişiklikleri.

Bir takip numarasının alınması ile kaydının onaylanması arasında kabul edilebilir maksimum süre gibi dahili bir kayıt hedefi belirleyin. Bunu takip güncelliğinden ayrı tutun: başarılı kayıt, taşıyıcı taramasının zaten mevcut olduğu anlamına gelmez.

Etkili kayıt kapasitesini hesaplayın

İstekle sınırlı bir kayıt uç noktası için yararlı bir planlama ilişkisi şöyledir:

Kayıt kapasitesi = saniye başına izin verilen istek sayısı × istek başına ortalama kayıt sayısı × başarılı kayıt oranı

Bu bir planlama tahminidir, sağlayıcı garantisi değildir. İstek limitlerinin bağlayıcı kısıt olduğunu varsayar. Kayıt tabanlı kotalar, yük boyutu, gecikme ve paylaşılan hesap limitleri daha düşük bir üst sınır getirebilir.

Yalnızca örnek olarak, bir entegrasyonun saniyede iki kayıt isteğine izin verildiğini ve her istekte ortalama 30 kayıt gönderdiğini varsayalım. Başarısızlıklar ve diğer kısıtlar öncesinde nominal kapasitesi saniyede 60 kayıttır. Sürekli bir yoğunluk sırasında gelen kayıtlar saniyede ortalama 80 kayıt ise kuyruk saniyede yaklaşık 20 kayıt artar. Bu rakamlar varsayımsaldır; 17TRACK limitleri değildir.

Kurtarma kapasitesini de hesaplayın. Yeni gelişler λ hızında devam ediyor ve etkin işleme kapasitesi μ ise B kayıttan oluşan mevcut birikmiş işin, μ > λ olduğunda boşaltılması yaklaşık B / (μ − λ) saniye sürer. İşleme kapasitesi geliş hızını aşmıyorsa birikmiş iş bu koşullar altında temizlenemez.

Sağlayıcının gerçekte neyi sınırladığını doğrulayın

Hız limiti ile kullanım kotası farklı sorunları çözer. Hız limiti, isteklerin veya kayıtların ne kadar hızlı gönderilebileceğini kontrol eder. Kullanım kotası, bir hesabın faturalandırma veya yetkilendirme dönemi boyunca tüketebileceği takip etkinliği miktarını kontrol edebilir. Birinin altında kalmak, diğerine uyulduğunu göstermez.

Çalışan sayılarını belirlemeden önce aşağıdakileri sağlayıcının belgelerine ve hesap koşullarınıza göre doğrulayın:

• Limitlerin hesap, API anahtarı, uç nokta, IP adresi veya başka bir kapsam için geçerli olup olmadığı.
• Sayım biriminin istek, takip kaydı veya başka bir işlem olup olmadığı.
• Uç noktaların ortak bir limit kullanıp kullanmadığı veya bağımsız izinlere sahip olup olmadığı.
• Tek bir istekte izin verilen maksimum kayıt ve yük boyutu.
• Yinelenen gönderimlerin, geçersiz kayıtların ve yeniden denemelerin kullanımı nasıl etkilediği.
• Yanıtların kısıtlama bilgileri veya yeniden deneme yönergeleri sunup sunmadığı.
• Kota tükenmesinin geçici kısıtlamadan nasıl farklı olduğu.

Bir 17TRACK entegrasyonu için bu yapılandırmanın başlangıç noktası olarak resmi Tracking API sayfasını ve API belgelerini kullanın. Dağıtımdan önce geçerli uç nokta davranışını ve hesap limitlerini doğrulayın. Bu kılavuzdaki örnek kapasiteler mimari açıklamalardır; 17TRACK yetkileri, toplu işlem boyutları veya hizmet garantileri hakkında beyan değildir.

Sipariş işleme ile kayıt arasına dayanıklı bir kuyruk yerleştirin

Ödeme veya depo tamamlanma süreçlerini bir takip sağlayıcısının kaydı kabul etmesini bekleyecek şekilde tasarlamayın. Gönderiyi yerel olarak kalıcı hale getirin, kayıt görevini dayanıklı biçimde kaydedin ve gönderimi arka plan çalışanlarının gerçekleştirmesine izin verin.

Uygulanabilir bir akış şöyledir:

1. Gönderiyi ve kayıt niyetini kaydedin. Siparişi kaydederken arka plan görevini kaybetmemek için işlemsel outbox veya eşdeğer bir tasarım kullanın.
2. Girdileri doğrulayın ve normalleştirin. Başındaki sıfırlar dahil olmak üzere takip numaralarını dize olarak koruyun. Taşıyıcıya özgü normalleştirmeyi yalnızca gerekli olduğunda uygulayın.
3. Mevcut bir kaydı kontrol edin. Sağlayıcıya ve veri modelinize uygun kararlı bir kimlik kullanın.
4. Uygun kayıtları kuyruğa alın. Deneme sayısını, bir sonraki uygun yeniden deneme zamanını ve tanılama için yeterli bağlamı saklayın.
5. Paylaşılan bir sınırlayıcı üzerinden gönderin. Kapasiteyi giden istekten hemen önce alın.
6. Kayıt düzeyindeki sonuçları kalıcı olarak saklayın. Onaylanmış başarıyı, yeniden denenebilir hatayı, kalıcı reddi ve belirsiz sonuçları birbirinden ayırın.

Kuyruk bir yoğunluğu absorbe eder; sağlayıcı kapasitesi oluşturmaz. Uygun durumdaki en eski kaydın yaşı sürekli artıyorsa çalışan sayısını artırmak yerine geliş hızı ile işleme kapasitesi arasındaki farkı araştırın.

Limitleri çalışanlar arasında koordine edin

Bağımsız çalışanların her biri hesabın tüm kapasitesini kullanabileceğini varsaymamalıdır. Koordine edilmiş bir hız sınırlayıcı veya paylaşılan istek bütçesi tahsis eden bir dağıtıcı kullanın. Zamanlanmış içe aktarmaları, operasyonel betikleri ve mutabakat işlerini de bu bütçeye dahil edin.

Hız ve eşzamanlılık farklı kontrollerdir. Sınırlayıcı, isteklerin ne sıklıkta başlatılacağını kontrol eder; eşzamanlılık sınırı ise aynı anda kaç isteğin devam edebileceğini kontrol eder. Sağlayıcı gecikmesi arttığında her ikisi de yararlıdır. Eşzamanlılığı artırmak gecikme sınırlı bir iş yüküne yardımcı olabilir, ancak giden hız limitini aşamaz.

Kayıt düzeyindeki kontrolü kaybetmeden toplu kayıt kullanın

Bir uç nokta istek başına birden fazla kaydı destekliyorsa toplu işlem istek yükünü azaltabilir. Bu, kayıt tabanlı kullanımı mutlaka azaltmaz ve izin verilen en büyük toplu işlem boyutu her zaman en iyi operasyonel seçim değildir.

Toplu işlemleri iki tetikleyici kullanarak oluşturun: maksimum kayıt sayısı ve maksimum bekleme süresi. Bunlardan biri karşılandığında gönderin. Böylece yoğun dönemlerde toplu işlemler verimli biçimde doldurulurken düşük hacimli trafik sonsuza kadar beklemek zorunda kalmaz.

• Kayıt sayılarına ek olarak yük limitlerine de uyun. İsteğe bağlı meta veriler, aynı boyuttaki toplu işlemlerin bayt cinsinden çok farklı olmasına neden olabilir.
• Dahili bir toplu işlem manifestosu tutun. Hangi yerel gönderi kimliklerinin gönderildiğini kaydedin ve dönen her sonucu doğru kayıtla ilişkilendirin.
• Uygulama düzeyindeki sonuçları inceleyin. Bir HTTP başarı yanıtı tek başına her kaydın kabul edildiğini kanıtlamaz.
• Yalnızca yeniden denenmesi gereken kayıtları yeniden deneyin. Başarılı kayıtları yeniden oynatmak gereksiz trafik oluşturur ve kullanım sonuçları doğurabilir.
• Kalıcı doğrulama hatalarını düzeltmeye yönlendirin. Değiştirilmemiş geçersiz bir yük yeniden deneme kuyruğunda dolaşmamalıdır.

Zaman aşımı özellikle önemlidir: istemciniz yanıtı almasa bile sağlayıcı isteği kabul etmiş olabilir. Bu sonucu belirsiz olarak işaretleyin. Desteklenen bir idempotency mekanizması, belgelenmiş bir yinelenen kayıt kuralı veya mevcutsa mutabakat sorgusu aracılığıyla çözümleyin. Zaman aşımına uğramış bir yazma işleminin başarısız olduğunu varsaymayın.

Canlı trafiği geçmişe dönük içe aktarmalardan ayırın

Bir geri doldurma işlemi yeni gönderilen gönderiler için gereken tüm kapasiteyi tüketmemelidir. Ağırlıklı zamanlama veya açık kapasite rezervasyonlarıyla ayrı kuyruklar kullanın. İçe aktarmaların kullanılmayan kapasiteden yararlanmasına izin verirken canlı kayıtlar için minimum bir tahsis koruyun. Düşük öncelikli kayıtların sonunda işlenmesini sağlamak için yaşlandırma veya başka bir adalet kuralı uygulayın.

Yeniden denemeleri kontrollü, gecikmeli ve sınırlı hale getirin

HTTP 429 “Too Many Requests” anlamına gelir. RFC 6585, bir 429 yanıtının Retry-After başlığı içerebileceğini belirtir. RFC 9110, bu başlığın değerini HTTP tarihi veya saniye cinsinden gecikme olarak tanımlar. İstemci, her zaman bir tam sayı döndürüldüğünü varsaymak yerine her iki biçimi de ayrıştırmalıdır.

Geçerli bir yeniden deneme gecikmesi sağlandığında süre dolmadan yeniden denemeyin. Yeniden deneme yönergesi yoksa jitter içeren sınırlı üstel geri çekilme kullanın: denemeler arasındaki gecikmeyi kademeli olarak artırın ve çalışanların aynı anda yeniden denememesi için rastgelelik ekleyin. Yeniden denemeler, ilk denemelerle aynı giden sınırlayıcıdan geçmelidir.

Yeniden denemeden önce hataları sınıflandırın:

• Kısıtlama: Etkilenen işi geciktirin ve ilgili limit kapsamındaki gönderim baskısını azaltın.
• Geçici ağ veya sunucu hataları: Belirsiz yazma sonuçlarını hesaba katan sınırlı bir politika dahilinde yeniden deneyin.
• Kimlik doğrulama veya yetkilendirme hataları: Kimlik bilgileri veya izinler düzeltilene kadar uyarı verin ve etkilenen işleri duraklatın.
• Doğrulama hataları: Kaydı değiştirmeden yeniden göndermek yerine düzeltin veya izole edin.
• Tükenmiş kullanım kotası: Bunu kısa süreli bir trafik yoğunluğu olarak ele almak yerine belgelenmiş hesap çözümünü uygulayın.

Hem deneme limiti hem de maksimum yeniden deneme yaşı belirleyin. Tükenen öğeleri neden, sorumlu kişi ve yeniden oynatma prosedürüyle birlikte bir dead-letter kuyruğuna taşıyın. Aksi takdirde eski hatalar, yeni gönderiler için ayrılan kapasiteyi sessizce tüketebilir.

Webhook alımını bağımsız olarak ölçeklendirin

Sağlayıcı uygun webhook'lar sunuyorsa bunlar tekrarlanan durum sorgularını azaltabilir. Ancak güncelleme yoğunlukları sırasında kullanılabilir kalması gereken ayrı bir gelen iş yükü de oluştururlar.

Alım uç noktasını odaklanmış tutun: isteği sağlayıcının belgelenmiş mekanizmasını kullanarak doğrulayın, etkinliği kalıcı olarak saklayın ve gereken onayı döndürün. Sipariş değişikliklerini, analizleri ve müşteri mesajlarını asenkron olarak işleyin. Etkinliği kaybetme riski varsa kalıcı kabulden önce alındı onayı vermeyin.

Sağlayıcı sözleşmesi açıkça farklı bir davranış belirlemedikçe tüketicileri yinelenen teslimatları tolere edecek şekilde tasarlayın. Yinelenenleri ayırt etmek için belgelenmiş kararlı bir etkinlik kimliğini tercih edin. Böyle bir kimlik yoksa bileşik kimliği dikkatle tasarlayın ve test edin: yalnızca bir durum etiketini kullanmak farklı etkinlikleri tek bir etkinlikte birleştirebilir.

Sırası değişmiş güncellemelere karşı da koruma sağlayın. Etkinlik geçmişini türetilmiş mevcut gönderi durumundan ayrı saklayın. Mevcut olduğunda belgelenmiş etkinlik zaman damgalarını ve geçiş kurallarını uygulayın; geliş sırasının etkinlik sırası olduğunu veya gönderi durumlarının evrensel olarak artan bir sıra oluşturduğunu varsaymayın.

Mutabakatı hedefli ve hız sınırlı tutun. Şüpheli teslimat boşluklarını veya belirsiz kayıtları araştırabilir, ancak her gönderiyi agresif biçimde sorgulamak webhook'ların önlemek üzere tasarlandığı giden yükü yeniden oluşturabilir.

Yalnızca maksimum aktarım hızını değil, kurtarmayı da test edin

Sağlayıcı simülatörü kullanarak kendi bileşenlerinize yönelik yük testleri gerçekleştirin. Canlı sağlayıcıya önemli miktarda trafik gönderen testleri koordine edin ve yetkilendirilmiş limitler içinde kalın. Başarılı bir test, sistemin yalnızca büyük bir yoğunluğu kabul ettiğini değil, kesintiden sonra normale döndüğünü de göstermelidir.

• Depo tarzı bir yoğunluğu ve ardından devam eden normal trafiği yeniden oynatın.
• Kısıtlama yanıtları, yükseltilmiş gecikme ve geçici sunucu hataları ekleyin.
• Kısmi toplu işlem reddini ve sunucu tarafında kabulden sonra gerçekleşen zaman aşımını simüle edin.
• Yinelenen ve sırası değişmiş webhook etkinlikleri teslim edin.
• Veritabanı erişimini kesin ve kabul edilmemiş etkinliklerin yanlışlıkla onaylanmadığını doğrulayın.
• Canlı kayıtlarla birlikte geri doldurma çalıştırın ve adaleti kontrol edin.
• Dead-letter öğelerini hız kontrollerini atlamadan yeniden oynatın.

Uygun durumdaki en eski kaydın yaşını, kabul gecikmesini, kayıt düzeyindeki başarı oranını, kısıtlama sıklığını, yeniden deneme hacmini, webhook işleme gecikmesini ve dead-letter büyümesini izleyin. Yalnızca kuyruk derinliği yeterli değildir: büyük bir kuyruk hızla boşalabilirken küçük bir kuyruk, sürekli başarısız olan birkaç kritik gönderi içerebilir.

Yoğun sezon öncesinde operasyonel sorumluluğu atayın. Mühendislik ekibi gönderim kontrolleri ve kurtarma araçlarından, entegrasyon sahibi sağlayıcı yetkilerini doğrulamaktan, operasyon ekibi ise hangi gönderilere öncelik verileceğini tanımlamaktan sorumlu olmalıdır. İçe aktarmaların ne zaman duraklatılacağını, ek kapasitenin ne zaman talep edileceğini veya eksik güncellemelerin ne zaman araştırılacağını belgeleyin. En güçlü tasarım, trafik anlık işleme kapasitesini aştığında da öngörülebilirliğini koruyan tasarımdır.

SSS

API anahtarları eklemek aktarım hızını artırır mı?

Gerekli olarak değil. Birden fazla anahtar hesap düzeyindeki aynı kotayı paylaşabilir. Limit kapsamını ve izin verilen ölçeklendirme yaklaşımını sağlayıcıyla doğrulayın. Kısıtlamaları aşmak için anahtar rotasyonu kullanmayın.

Her kayıt mümkün olan en büyük toplu işlemle mi gönderilmelidir?

Hayır. Daha büyük toplu işlemler istek verimliliğini artırabilir, ancak bunları doldurmayı beklemek düşük hacimde gecikmeyi artırır. Belgelenmiş bir boyut üst sınırı ve gönderme zamanlayıcısı kullanın, ardından ölçülen kabul gecikmesine ve hata davranışına göre ayarlayın.

Zaman aşımından sonra yinelenen kayıtlar nasıl önlenebilir?

Kalıcı yerel gönderi kimliğini ve sağlayıcının belgelenmiş idempotency veya yinelenen işlem davranışını kullanın. Sonuç belirsizliğini koruyorsa yeniden oynatmadan önce desteklenen yerde mutabakat yapın. Yalnızca yerel deduplikasyon, uzak isteğin başarılı olup olmadığını kanıtlayamaz.

Başarılı kayıt, takip bilgilerinin güncel olduğu anlamına mı gelir?

Hayır. Kayıt kabulü, taşıyıcı etkinliğinin kullanılabilirliği, sağlayıcı işleme süreci ve kendi güncelleme işlemeniz ayrı aşamalardır. Geciken taşıyıcı taramasının kayıt birikmiş işiyle karıştırılmaması için bunları ayrı ayrı ölçün.

Bir ekip ne zaman sağlayıcıdan daha fazla kapasite talep etmelidir?

Öngörülen gelişler ve gereken kurtarma süresi, önlenebilir yeniden denemeler, yinelenen gönderimler ve verimsiz toplu işlemler çıkarıldıktan sonra doğrulanmış kullanılabilir kapasiteyi aştığında talep edin. Daha büyük bir kota, engellenmiş bir tüketiciyi veya veritabanı darboğazını çözmez; bu nedenle önce bağlayıcı kısıtı belirleyin.

Kaynaklar

• 17TRACK Tracking API — API hizmeti için resmi başlangıç noktası.
• 17TRACK API documentation — entegrasyon gereksinimlerini, uç nokta davranışını ve geçerli istek kısıtlarını kontrol etmek için referans.
• RFC 6585, Section 4: 429 Too Many Requests — HTTP kısıtlama semantiği ve isteğe bağlı Retry-After yönergeleri.
• RFC 9110, Section 10.2.3: Retry-After — HTTP tarihi ve saniye cinsinden gecikme biçimleri.
• RFC 9110, Section 9.2.2: Idempotent Methods — bir isteğin sonucu belirsiz olduğunda yeniden deneme hususları.