Sessiz 429 rate limit 40.000 içe aktarılan Instagram gönderisini sildi; postmortem asenkron içe aktarım öneriyor

dev.to'da yazan bir geliştirici, platformlarına 40.000 içe aktarılmış Instagram gönderisine mal olan bir arızanın postmortem'ini yayımladı. Üçüncü taraf bir API sessiz 429 rate-limit hataları döndürmeye başlarken önyüzdeki yüklenme göstergesi dönmeye devam ediyordu; bu yüzden kullanıcıların göçümün takıldığına ya da öldüğüne dair hiçbir sinyali yoktu.

İçe aktarım nasıl başarısız oldu

dev.to yazısına göre ekip, özelliği basit bir dosya yükleme gibi kurmuştu: sürükle-bırak alanı senkron bir uca bağlıydı ve dış platformun API'sinin büyük medya kütüphanelerini sorunsuz akıtacağı varsayılıyordu. Gerçekte ise yukarı akış API'si ağır sayfalanmış, kısıtlanmış ve ani şema değişikliklerine eğilimliydi.

Senkron bir istek yaklaşık otuz saniye sonra zaman aşımına uğruyor, tarayıcı bağlantıyı kesiyor ve kullanıcı, içeriğinin ulaşıp ulaşmadığını mı yoksa yok olup olmadığını mı bilmeden boş bir ekrana bakakalıyordu. Kısmi başarısızlıklar veritabanındaki hasarı katlıyordu: yetim kayıtlar, thumbnail'siz videolar, kodlama uyuşmazlıklarıyla kesilen açıklamalar ve batch ortasında süresi dolan authentication token'ları. Destek ekibi sonunda üretim ortamında bozuk kullanıcı hesaplarını elle yamalamak zorunda kaldı.

Yazar, en büyük maliyetin güven olduğunu savunuyor. Sosyal medya yöneticileri ve içerik üreticileri yeni bir araca geçmeden önce kütüphanelerini düzenlemekle saatler harcar; onboarding'ın ilk dakikalarındaki sessiz bir başarısızlık, ürüne olan güvenlerini kalıcı olarak yok edebilir.

Önerilen çözüm: kaldığı yerden devam edilebilir background job'lar

Yeniden tasarımın merkezinde, kullanıcının tarayıcı oturumunu içe aktarımın ağır işinden ayırmak var. Monolitik bir API yanıtını beklemek yerine, her içe aktarım bir worker havuzu tarafından yürütülen asenkron, kaldığı yerden devam edilebilir ve gözlemlenebilir bir background task'a dönüşüyor.

Kullanıcı Instagram, TikTok veya YouTube'dan bir içe aktarım başlattığında önyüz, backend'e bir payload referansı veriyor ve kalıcı bir background drawer render ediyor. Bu drawer kırılgan, uzun ömürlü bir HTTP isteğine bağlı değil; WebSocket'ler ya da Redis durum önbelleği destekli polling aracılığıyla gerçek zamanlı durum güncellemelerine abone oluyor.

Ağ düşerse, kullanıcı sayfayı yenilerse ya da dış API istekleri kısıtlarsa sistem başarısız olmak yerine duraklıyor. Tam cursor konumunu kaydediyor, üstel geri çekilme (exponential backoff) ile bir yeniden deneme zamanlıyor ve kullanıcıya içe aktarma hızının geçici olarak platform limitleri tarafından kısıtlandığını, ayrıca gözlemlenen iş hacmine göre uyum sağlayan tahmini kalan süreyi açıklayan sakin bir banner gösteriyor.

Uygulama deseni

Yazı stack'i TypeScript olarak tasvir ediyor. Bir BullMQ worker içe aktarmaları kontrollü batch'ler halinde işliyor ve bir yanıtta daha fazla sayfa olduğunu gösterdiğinde worker, rate-limit hafifletmesi olarak bilinçli iki saniyelik bir gecikmeyle bir sonraki cursor'ı taşıyan takip bir job'unu kuyruğa ekliyor. Her chunk küçük ve değişmez (immutable) olduğundan, geçici bir başarısızlık tüm göçümü değil yalnızca bir batch'i etkiliyor ve istek zaman aşımları fiilen ortadan kalkıyor.

İstemcide bir React hook'u Server-Sent Events akışı açıyor ve progress ile error alanlarının yanı sıra kompakt bir durum makinesini — idle, processing, paused, completed, failed — takip ediyor. Yardımcı bir Express route'u ilk job'u elli(batch boyutu ile kuyruğa sokuyor ve hemen HTTP 202 Accepted ile bir job tanımlayıcısı döndürüyor; böylece içe aktarım ne kadar büyük olursa olsun ilk yanıt hızlı kalıyor.

Makale, kaçınılması gereken diğer hataları kataloglayan bir bölümle kapanıyor; ancak yayımlanan metin bu tartışmanın ortasında kesiliyor.

Neden önemli

Üçüncü taraf API'lerden veri içe aktaran her ürün, onların titizliğini miras alır. Burada aktarılabilir ders şudur: senkron istekler artı belirsiz spinners, yukarı akış kısıtlamasını sessiz veri kaybına dönüştürür — ve kullanıcılar 429 döndüren platformu değil ürününüzü suçlar.

İçe aktarmaları parçalı, cursor tabanlı, kaldığı yerden devam edilebilir job'lar olarak modellemek sert bir başarısızlığı duraklamaya dönüştürür; gerçek pipeline durumunu (kısıtlama dahil) yansıtan bir UI de kafa karışıklığını açıklanabilir bir bekleme dönüştürür. Aynı desen sosyal medya içe aktarımlalarının çok ötesinde geçerlidir: faturalandırma senkronizasyonları, CRM göçleri, toplu dışa aktarmalar ve rate-limit'li bir sınır boyunca büyük hacimli veri çeken diğer her pipeline aynı mimariden faydalanır.