Rate limiting, bir API'nin belirli bir zaman penceresinde kabul edebilecegi istek sayisini sinirlayarak hem altyapi kaynaklarini korur hem de adil kullanım sağlar. Kotu niyetli trafik, hatali retry donguleri veya beklenmedik viral yük artislari olmadan bile her servis belirli bir kapasiteye sahiptir; sınır asildiginda kontrollu bir reddetme mekanizmasi olmazsa tüm tuketiciler gecikme ve hata dalgalari yasar. Iyi tasarlanmis bir hiz sinirlamasi politikasi, tuketici deneyimini korurken operasyonel dayanikliligi artirir.
Hiz sinirlamasinin temel hedefleri
API rate limiting uc ana hedefe hizmet eder: kaynak koruma, adil paylaşım ve güvenlik. Veritabanı bağlantı havuzu, CPU ve bellek gibi sinirli kaynaklar tek bir agresif istemci tarafindan tuketilebilir. Adil paylaşım, her tuketicinin veya tenant'in makul bir kota icinde kalmasini garanti eder. Güvenlik acisindan brute force, credential stuffing ve scraping saldirilarinin maliyeti artirilarak etkisi azaltilir.
Kimlik bazli vs IP bazli sınırlar
IP adresi uzerinden sinirlama basit uygulanir ancak NAT, kurumsal proxy ve mobil ag gecisleri nedeniyle birden fazla gerçek kullanıcıyı tek bucket altinda toplayabilir. OAuth client_id, API anahtari veya kullanıcı kimligi uzerinden sinirlama daha adil sonuç verir. Hibrit modelde anonim istekler IP ile, kimlik dogrulanmis istekler token ile sinirlanir.
- Global limit: Tüm API icin toplam kapasite tavanı.
- Endpoint limit: Agir işlemler icin daha düşük kota.
- Tenant limit: Cok kiracili sistemlerde organizasyon bazli kota.
- Burst limit: Kisa sureli ani yük artisina izin.
Token bucket algoritmasi
Token bucket, belirli bir hizda token ureten ve her istekte bir token harcayan klasik bir algoritmadir. Kova dolu oldugunda fazla token birikmez; bos oldugunda istek reddedilir veya kuyruga alinir. Bu model burst trafigine izin verir: uzun sure sessiz kalan bir istemci biriken tokenlari kisa surede harcayabilir.
class TokenBucket {
capacity: number; // max token
tokens: number;
refillRate: number; // token/saniye
lastRefill: number;
allow(): boolean {
this.refill();
if (this.tokens >= 1) { this.tokens -= 1; return true; }
return false;
}
}Token bucket Redis uzerinde INCR ve EXPIRE kombinasyonu veya Lua script ile atomik uygulanabilir. Dagitik ortamda her gateway node'unun kendi bellek icinde bucket tutmasi tutarsiz sinirlara yol acar; merkezi veya tutarlı hash tabanli dagitim tercih edilir.
Sliding window ve fixed window
Fixed window algoritmasi her dakika veya saat basinda sayaci sifirlar. Uygulamasi kolaydir ancak pencere sinirlarinda cift patlama problemi olusur: bir istemci pencere sonunda ve basinda maksimum istegi gonderebilir, kisa surede iki kat yük olusur.
Sliding window log her istegin zaman damgasini tutar ve son N saniyedeki istek sayisini sayar. Daha hassastir ancak bellek maliyeti yüksektir. Sliding window counter, log ile counter arasinda pratik bir orta yol sunar: önceki ve mevcut pencere agirlikli ortalamasini kullanır.
Algoritma karsilastirmasi
- Fixed window: Düşük bellek, sınır patlamasi riski.
- Sliding window log: Yüksek hassasiyet, yüksek bellek.
- Token bucket: Burst destegi, yumuşak sınır.
- Leaky bucket: Sabit çıkış hizi, trafik duzlestirme.
HTTP yanıt sozlesmesi
IETF taslagi ve endustri uygulamalari 429 Too Many Requests durum kodunu standart reddetme yaniti olarak kullanır. Istemcinin ne zaman tekrar deneyebilecegini belirtmek icin asagidaki basliklar kullanılır:
HTTP/1.1 429 Too Many Requests
Retry-After: 42
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1710000060
Content-Type: application/problem+jsonRetry-After saniye veya HTTP tarih formatinda olabilir. Istemci kutuphaneleri bu basligi okuyarak exponential backoff yerine sunucunun onerdigi süreyi kullanabilir. Tutarlı header isimlendirmesi dokumantasyonda açıkça tanimlanmalidir.
Katmanli sinirlandirma mimarisi
Rate limiting tek noktada uygulanabilir veya katmanli olabilir. Edge CDN veya API gateway ilk savunma hattidir; uygulama sunucusu is mantigi bazli ince ayar yapar; veritabanı katmanı connection pool korumasi sağlar.
Gateway vs uygulama katmanı
Gateway seviyesindeki sınırlar genel trafik kontrolu icin yeterlidir. Ancak POST /orders ile GET /health ayni kotayi paylasirsa adalet bozulur. Endpoint bazli politika tanimlari gateway konfigurasyonunda veya policy engine uzerinden yönetilir.
- Edge: DDoS ve genel trafik tavanı.
- Gateway: Client ve route bazli kota.
- Service: Is kurallarina özel limit.
- Database: Sorgu basina timeout ve pool limiti.
Dagitik uygulama ve tutarlılık
Birden fazla API instance'i olan sistemlerde merkezi sayac gereklidir. Redis, Memcached veya dedicated rate limit servisi yaygın cozumlerdir. Yerel bellek cache'i yalnizca tek node ortamlarinda veya yaklasik sınırlar kabul edilebilir oldugunda kullanılır.
Redis Cluster veya sharding ile yüksek throughput sağlanır. Lua script atomik okuma-yazma garantisi verir. Circuit breaker ile Redis erisilemez oldugunda fail-open mi fail-closed mi davranilacagi bilincli karar verilmelidir; finansal API'lerde fail-closed tercih edilir.
Istemci tarafi en iyi uygulamalar
API tuketicileri 429 yanitlarini retry stratejisine dahil etmelidir. Exponential backoff ile jitter, thundering herd problemini azaltir. Idempotent GET istekleri guvenle tekrarlanabilir; POST ve PATCH icin idempotency key kullanımı zorunludur.
async function fetchWithRetry(url, opts, max = 5) {
for (let i = 0; i < max; i++) {
const res = await fetch(url, opts);
if (res.status !== 429) return res;
const wait = parseInt(res.headers.get('Retry-After') ?? '2', 10);
await sleep(wait * 1000 * (1 + Math.random() * 0.2));
}
throw new Error('Rate limit exceeded');
}Kota modelleri ve is mantigi
Teknik sinirlarin otesinde is modeli de rate limitingi sekillendirir. Freemium planlar düşük kota, enterprise planlar yüksek kota alir. Quota gunluk veya aylik toplam istek sayisini ifade eder; rate saniye basina istek hizini ifade eder. Ikisi birlikte calisabilir: saniyede 10 istek ama gunluk 10.000 istek tavanı.
Graceful degradation
Limit asildiginda yalnizca reddetmek yerine istege bağlı olarak düşük öncelikli islemleri geciktirmek veya cached yanıt donmek dusunulebilir. Okuma agirlikli API'lerde stale cache, yazma agirlikli API'lerde kuyruk tabanli işleme alternatif stratejilerdir.
Gozlemlenebilirlik ve alarm
Rate limit metrikleri operasyon icin kritiktir. Reddedilen istek orani, bucket doluluk orani ve en cok sinira takilan client listesi dashboard'da izlenmelidir. Ani artis saldırı veya entegrasyon hatasina isaret edebilir.
- 429 yanıt sayisi ve orani.
- Client bazli limit kullanımı.
- Endpoint bazli hot spot analizi.
- Retry-After uyum orani.
Güvenlik ve bypass riskleri
Rate limiting tek basina güvenlik çözümü degildir. IP rotasyonu, dagitik botnet ve çoklu hesap ile sınırlar asilabilir. WAF, bot detection ve kimlik dogrulama ile birlikte defense-in-depth yaklasimi gerekir. Internal servisler arasi ileisim icin mTLS ve servis mesh rate limit politikasi ayri tanimlanmalidir.
Test ve kapasite planlama
Load test senaryolarina rate limit dogrulamasi eklenmelidir. Sınır degerleri üretim verisi olmadan tahmin edilmemeli; p95 istek hacmi ve buyume projeksiyonu ile belirlenmelidir. Canary deploy sirasinda yeni limitlerin etkisi kademeli olculur.
Özet tasarım ilkeleri
Başarılı bir rate limiting stratejisi şeffaf header sozlesmesi, adil algoritma seçimi, katmanli uygulama ve ölçülebilir metrikler uzerine kurulur. Istemci gelistiricilerine net dokumantasyon ve örnek retry kodu sunmak entegrasyon kalitesini yukseltir. Sınırlar is hedefleriyle uyumlu olmali; cok düşük limit entegrasyonu zorlastirir, cok yüksek limit koruma saglamaz.
Token bucket burst ihtiyaci olan API'ler icin, sliding window hassas adalet gerektiren senaryolar icin uygundur. Dagitik ortamda merkezi sayac ve atomik işlemler tutarliligin temelidir. 429 yaniti ile Retry-After basligi, istemci ve sunucu arasindaki is birligini standartlastirir ve gereksiz retry firtinasini onler.
GraphQL ve batch istekler
GraphQL tek HTTP istegi icinde birden fazla resolver calistirabilir; geleneksel istek-basi limit yetersiz kalir. Query complexity ve depth limit ile birlikte maliyet bazli rate limiting uygulanir. Her sorguya puan atanir; puan tavanı asildiginda istek reddedilir.
Webhook ve çıkış trafigi
Sadece gelen istekler degil, webhook gonderimi ve üçüncü parti API cagrilari da sinirlanmalidir. Outbound rate limit, partner API'lerinin kotasini korumak ve retry maliyetini kontrol altinda tutmak icin gereklidir.
Regulasyon ve SLA
Bazi sektorlerde API erişim loglari ve limit uygulama kaniti denetim gerektirir. SLA'de belirtilen kota asimlarinda tuketici bilgilendirme ve faturalandirma kurallari onceden tanimlanmalidir. Limit artisi talepleri self-service portal veya destek kanali uzerinden yönetilebilir.
