Rate Limiting ve Load Shedding: Aşırı Yükte Ayakta Kalmak
Aşırı yük tasarımı: token bucket ve sliding window algoritmaları, dağıtık rate limiting, öncelikli yük atma (load shedding), graceful degradation ve adil kota stratejileri.
Sistem kapasitesinin üstünde trafik gelince ne olmalı?
Tasarlanmamış sistemlerde cevap bellidir: her istek biraz daha yavaşlar, kuyruklar dolar, zaman aşımı fırtınası başlar ve herkes için her şey çöker. Tasarlanmış sistemde ise cevap seçilmiştir: fazla trafik sınırda kibarca reddedilir, kritik işlevler korunur, sistem küçülerek ayakta kalır. Rate limiting ve load shedding, bu seçimin iki aracıdır — biri kapıda, biri içeride çalışır.
Rate limiting algoritmaları: doğru aracı seçmek
Algoritma | Davranış | Güçlü yanı | Dikkat |
|---|---|---|---|
Token bucket | Sabit dolum hızı + patlama (burst) kapasitesi | Kısa patlamalara tolerans; endüstri varsayılanı | Bucket boyutu = izinli patlama, bilinçli seçilmeli |
Leaky bucket | Çıkışı sabit hıza düzler | Arka sistemi düzgün akışla korur | Patlamaları kuyruklar; gecikme ekler |
Fixed window | Pencere başına sayaç | En basit uygulama | Pencere sınırında 2x patlama açığı |
Sliding window | Kayan pencerede ağırlıklı sayım | Sınır patlamasını kapatır; hassas | Biraz daha maliyetli sayım |
Pratik seçim çoğunlukla token bucket'tır (kullanıcı deneyimine saygılı patlama toleransı) veya sliding window'dur (hassas kota). Önemli olan algoritmadan çok politikadır: limit kime (IP, kullanıcı, API anahtarı, kiracı), hangi kaynakta (uç nokta bazında) ve hangi cevapla (429 + Retry-After başlığı) uygulanıyor?
Dağıtık limit: tek düğümün sayacı yetmez
N kopyalı bir serviste düğüm-yerel limit, gerçek limitin N katına izin verir; tutarlı sınır için sayaç merkezîleşir — pratikte Redis üzerinde atomik sayım (Lua betikli token bucket) endüstri standardıdır. İki mühendislik notu: limit kontrolü sıcak yolda olduğundan sayaç erişimi milisaniye altı kalmalı ve Redis erişilemezse politika bilinçli olmalıdır (fail-open: limitsiz devam — kullanılabilirlik öncelikli; fail-closed: reddet — koruma öncelikli). Bu karar, olay anında değil tasarımda verilir. Gateway katmanında hazır limit modülleri işin taşıyıcısıdır; iş-bilinçli kotalar (kiracı planına göre) uygulama katmanında tamamlanır.
Load shedding: içerideki son savunma
Rate limiting kapıdaki sözleşmedir; load shedding ise sistemin kendi sağlığına bakarak yük atmasıdır: kuyruk derinliği, bekleyen istek sayısı veya gecikme eşiği aşıldığında yeni isteklerin bir bölümü hızla reddedilir — çünkü hızlı 'hayır', yavaş 'evet'ten değerlidir: zaman aşımına sürüklenen istek hem kaynak tüketir hem istemcide retry tetikleyip yükü katlar. Atmanın da önceliği vardır: sağlık kontrolleri ve ödeme/sipariş gibi kritik akışlar korunur; arama önerisi, öneri kutusu, analitik gibi süsler önce atılır. Bu öncelik listesi teknik değil, iş kararıdır — ve kampanya öncesinde yazılmış olmalıdır.
Graceful degradation: küçülerek hizmet vermek
Yük atmanın kullanıcıya görünen yüzü zarif bozulmadır: öneri servisi cevap vermiyorsa sayfa önerisiz ama satın alınabilir gelir; stok servisi yavaşsa 'stok bilgisi birazdan' denir ama sepet çalışır; statik/önbellekli içerik, canlı içeriğin yedeği olur. Bunun ön koşulu bağımlılık haritasıdır: hangi bileşen olmadan sayfa 'yine de iş görür'? Her kritik akış için bu soru cevaplanır ve fallback davranışı kodlanır — degradation, olay günü doğaçlaması değil, önceden yazılmış senaryodur.
Retry fırtınası: iyi niyetli istemcilerin saldırısı
Aşırı yük anında en tehlikeli trafik, hatalara agresif retry ile cevap veren kendi istemcilerinizdir — her hata dalgası bir sonraki dalgayı büyütür. Sözleşme iki taraflıdır: sunucu 429/503 cevaplarında Retry-After verir; istemciler exponential backoff + jitter uygular ve retry bütçesiyle sınırlanır. Mobil uygulamalarınız ve entegrasyon istemcileriniz bu disiplinle yazılmadıysa, rate limiter'ınız kendi ekosisteminizle savaşır.
İş etkisi: kontrollü küçülme, kontrolsüz çöküşten ucuzdur
Aşırı yükte fark iki senaryo arasındadır: ya trafiğin %20'sini bilinçli reddedip %80'ine tam hizmet verirsiniz, ya %100'üne hizmet vermeye çalışıp %100'üne zaman aşımı yaşatırsınız. İlk senaryoda kampanya cirosunun büyük bölümü korunur, ikincisinde tamamı riske girer — üstelik çöküş sonrası toparlanma da ayrı maliyettir. Rate limiting aynı zamanda ticari altyapıdır: API planlarının kotaları, kiracı adaleti ve kötüye kullanım koruması aynı mekanizmadan beslenir.
Sık sorulan sorular
Limitler nasıl belirlenir?
Yük testiyle bulunan güvenli kapasiteden geriye doğru: sistem kapasitesi → uç nokta bütçeleri → aktör bazlı paylar. Tahminle konan limit ya erken keser ya geç korur.
429 kullanıcı deneyimini bozmaz mı?
Doğru uygulanırsa korur: patlama toleransı normal kullanıcıyı hiç görmez; sınırda ise net mesaj + Retry-After, sessiz zaman aşımından iyi deneyimdir.
Load shedding ile autoscaling çelişir mi?
Tamamlayıcıdır: autoscaling dakikalar ölçeğinde kapasite ekler; shedding saniyeler ölçeğinde köprü kurar. Ani zirvede önce shedding tutar, sonra yeni kapasite devralır.
Bot trafiğini rate limit mi çözer?
Tek başına değil: limit, hacmi sınırlar; bot yönetimi (davranış analizi, doğrulama) kaynağı ayıklar. İkisi birlikte kampanya günü stok adaletini korur.
Aşırı yük tasarımı kontrol listesi
Limit politikası yazılı: kim, hangi uç nokta, hangi algoritma, hangi cevap
Dağıtık sayaç kurulu; fail-open/closed kararı bilinçli
429/503 cevapları Retry-After taşıyor; istemciler backoff+jitter uyguluyor
Load shedding eşikleri ve öncelik listesi iş onaylı
Kritik akışların fallback davranışları kodlanmış ve test edilmiş
Retry bütçeleri iç istemcilerde ve SDK'larda tanımlı
Kampanya öncesi aşırı yük tatbikatı (chaos/yük testi) yapılıyor
SSH Yazılım, aşırı yük dayanımı tasarımını — limit politikasından degradation senaryolarına — uçtan uca kurar. Zirve gününüzü birlikte güvenceye alalım.