Burada ne görüyorsunuz

Dört producer en fazla 300 mesaj tutan bir kuyruğa yayın yapıyor; en fazla on iki consumer kuyruğun başından mesaj çekiyor ve her biri saniyede yaklaşık altı mesaj işliyor. Consumer’lar yetiştiği sürece kuyruk neredeyse boş kalıyor ve lag — bekleyen en eski mesajın yaşı — sıfıra yakın duruyor. Üretim hızını consumer’ların boşaltabileceğinin üstüne çıkar; derinlik ve lag birlikte tırmanıyor. Kuyruk kaynaklı olayların çoğunun bütün hikâyesi bu.

Backpressure ya da düşürmek

Sınırlı bir kuyruk dolduğunda bir şey yapmak zorunda. Backpressure açıkken derinlik %70’lik high-water mark’ı geçtiği anda producer’lar kalan boşlukla orantılı olarak yavaşlatılıyor — baskı yukarı akıyor; orada çağıran taraf bekleyebilir, yük atabilir ya da 429 dönebilir. Kapatırsan hiçbir şey yavaşlamıyor: kuyruk kapasitesine kadar doluyor ve yeni mesajlar yere düşüyor. İkisi de bedava değil ama sadece biri senin verdiğin bir karar.

Kuyruk uzunluğuna göre ölçekleme

KEDA açıkken consumer sayısı doğrudan kuyruğu takip ediyor: istenen replica = ⌈(bekleyen + işlenen) / 15⌉, belirlediğin maksimuma kadar. Scale-up anında oluyor ama yeni consumer’ların başlaması biraz sürüyor, bu yüzden lag toparlanmadan önce sıçrıyor; scale-down ise kısa bir sakinliğin salınıma yol açmaması için 5 saniyelik cooldown bekliyor. KEDA’yı kapat, iki consumer bırak ve Spike’a bas: çoğunlukla I/O bekleyen bir worker için CPU’ya göre ölçeklemenin neden yanlış sinyal olduğunu göreceksin.

Retry, zehirli mesaj ve dead-letter queue

Başarısız mesajlar üstel backoff ile (0.25 sn, 0.5 sn, 1 sn…) kuyruğun sonuna geri konuyor. Geçici hatalar — kararsız downstream — genelde ikinci denemede başarılı oluyor. Zehirli bir mesaj asla olmayacak: burada 1.2 sn asılı kalıp her seferinde başarısız oluyor. Üç retry ile dört denemeden sonra dead-letter’a gidiyor ve bir insan onu sonra inceleyebiliyor; sonsuz retry ile sonsuza kadar dönüyor ve altı tanesi consumer’ların yarısını hiçbir şey yapmadan meşgul tutmaya yetiyor. Sayılar simülasyon, zaman sıkıştırılmış.