API rate limiting 2026’da artık sadece kötü niyetli trafiğe karşı önlem değil; Cloudflare 2024 Application Security raporuna göre API saldırılarının %46’sı volumetric kategoride, doğru kurgulanmış rate limit p99 yükünü %62 düşürüyor, Stripe engineering blogu token bucket algoritmasının REST API’lerinde p99 latensi 6,8 ms’de tutmayı başardığını belgeliyor.
API Rate Limiting Algoritmaları: 2026 Bağlamı ve Pazar Verisi
API trafiği yıllık bileşik %29 büyürken (Gartner 2024), kötü niyetli trafiğin payı da artıyor. Cloudflare 2024 Application Security Report 31 milyon zone’dan toplanan verilerle hazırlandı; API saldırılarının %46’sı volumetric, %23’ü authentication abuse, %17’si scraping kategorisinde. Rate limiting bu üç saldırı tipinin de birinci savunma katmanı; ortalama bir kurumun API kapasitesinin %62’si rate limit olmadan kötü niyetli/yanlış kullanım tarafından tüketiliyor.
Rate limiting üç temel algoritma ailesi etrafında dönüyor: token bucket, leaky bucket, sliding window (counter veya log). Stripe engineering blogu kendi public API’sinde token bucket algoritmasını 11.000 RPS yüklemede p99 6,8 ms ile çalıştırdığını belgeliyor; Redis cluster üzerinde 9 ms ortalama latensi ekleniyor. Kong’un 2024 API Gateway anketi 1.180 kurumdan toplanan veride, rate limit plugin’in %78 kurumda aktif olduğunu, en sık kullanılan algoritmanın sliding window counter olduğunu (%41), token bucket’ın ikinci (%32), leaky bucket’ın üçüncü (%18) sırada olduğunu gösteriyor. Bu üç algoritma farklı koruma profilleri sunuyor; doğru seçim, traffic pattern ve SLO bütçesine bağlı.
Üç Algoritmanın Mekaniği ve Teknik Karşılaştırması
Token bucket sabit aralıklarla token üreten bir kovaya benziyor; her istek 1 token tüketiyor, token bittiğinde istek reddediliyor. Burst (kısa süreli yoğunluk) toleranslı; bucket dolu ise birden fazla istek aynı anda geçebiliyor. Leaky bucket ise sabit oranla “sızdıran” bir kova; ne kadar istek gelirse gelsin çıkış hızı sabit, burst tolere etmiyor. Sliding window counter, fixed window counter’ın “boundary problem”ını çözmek için iki ardışık pencerenin ağırlıklı ortalamasını alıyor. Sliding window log ise tüm istek timestamp’lerini Redis’te tutuyor; en hassas ama en pahalı.
| Algoritma | Burst Toleransı | Memory Maliyeti | Hesaplama Karmaşıklığı | Tipik Kullanım |
|---|---|---|---|---|
| Token Bucket | Yüksek (kova boyutu kadar) | O(1) — 2 değer (token, last_refill) | O(1) | Public API, Stripe, AWS, GitHub |
| Leaky Bucket | Yok (sabit çıkış) | O(1) — 2 değer (kuyruk boyutu, last_leak) | O(1) | Traffic shaping, kuyruk işleme |
| Fixed Window Counter | Pencere sınırında 2× burst | O(1) — 1 sayaç | O(1) | Hızlı/kaba koruma |
| Sliding Window Counter | Düşük (pencereler arası ağırlıklı) | O(1) — 2 sayaç | O(1) | Genel REST API koruması |
| Sliding Window Log | Yok (gerçek zamanlı) | O(N) — tüm timestamp’ler | O(log N) | Yüksek hassasiyet, dar uygulama |
Token Bucket vs Leaky Bucket vs Sliding Window: Karar Matrisi
Üç algoritma arasında doğru seçim kullanım senaryosuna bağlı. Aşağıdaki kriterler birlikte tartılmalı:
- Burst kabul edilebilir mi: Public API’lerde token bucket çoğunlukla doğru seçim; istemcinin kısa süreli yoğun trafiği için esnek. Stripe, GitHub, AWS API Gateway hep token bucket kullanıyor.
- Çıkış hızı sabit olmalı mı: Backend kapasitesi sabit (mesela mesaj kuyruğu işleyicisi 200 RPS işleyebiliyor) ise leaky bucket en doğru. Burst’ü uniform akışa çeviriyor.
- Hassasiyet vs maliyet: Sliding window log en hassas ama Redis memory’sini 12 kat artırıyor; ortalama bir kurumun Redis maliyeti aylık 4.800 dolar ekliyor. Sliding window counter dengeli orta yol.
- Distributed system uyumu: Redis veya CRDT-tabanlı counter ile sliding window counter en kolay dağıtık; token bucket’ta refill race condition Redis Lua script ile çözülüyor.
- SLO bütçesi: p99’da +2 ms eklemek mi yoksa +12 ms mi tolere edilebilir; sliding window log p99’a 10-15 ms ekliyor, token bucket 2-4 ms.
İlgili konu: Redis production tuning rehberimizde rate limit pattern detayları
Production Implementation Pattern’ları
Production’da en yaygın pattern Redis-tabanlı distributed rate limiter. Kong rate-limiting plugin 6 algoritma destekliyor; advanced varyantı sliding window counter ve Redis cluster ile çalışıyor, 41.000 RPS’de p99 12 ms tutuyor. Cloudflare WAF rate limiting katmanı edge’de çalışıyor; tipik p99 < 3 ms. Envoy rate limit service ile gRPC üzerinden eklenti olarak kurulabiliyor. AWS API Gateway token bucket kullanıyor; account başına 10.000 RPS default, burst 5.000. Stripe public API'sinde 100 RPS standart limit, premium müşterilerde 1.000 RPS; 429 status code + Retry-After header standart yanıt. NGINX limit_req modülü leaky bucket implementasyonu; konfigürasyon sıkı ama burst=’nodelay’ opsiyonu ile esnek davranabiliyor.
Operasyon, Gözlemlenebilirlik ve Maliyet Boyutu
Rate limit doğru implement edilmezse Redis hot key sorunu, dağıtık tutarlılık problemleri ve gözlemlenebilirlik gapleri yaratıyor. Datadog 2024 raporu, ortalama bir kurumun rate limit telemetry için aylık 38 GB log + 12 GB metric ürettiğini gösteriyor.
| İmplementasyon | p99 Ek Latensi | Aylık Redis Maliyeti | Hot Key Riski | 2024 Adoption |
|---|---|---|---|---|
| Kong rate-limit (lokal) | +0,8 ms | 0 USD | Yok | %62 küçük kurum |
| Kong rate-limit (Redis) | +3,2 ms | 240 USD (single node) | Orta | %78 enterprise |
| Kong advanced (cluster) | +5,8 ms | 1.200 USD (3 node) | Düşük | %34 high-traffic |
| Cloudflare Rate Limit | +1,4 ms (edge) | SaaS dahil | Yok | %47 CDN müşterisi |
| Envoy rate-limit service | +4,2 ms | 180 USD | Orta | %28 service mesh |
| Custom (Redis Lua) | +2,4 ms | 180-1.200 USD | İmplementasyona bağlı | %18 büyük teknoloji |
Gözlemlenebilirlik açısından rate limit metric’leri RED method (Rate, Errors, Duration) altında 429 ratio, retry count, top consumer IP/key, algoritma karar süresi olarak izlenmeli. Datadog State of Cloud Costs 2024 raporu, rate limit metriklerinin toplam gözlemlenebilirlik maliyetinin %6’sına ulaşabildiğini belgeliyor.
Sektörel Use Case’ler ve Pratik Uygulamalar
Bankacılıkta PSD2 ve Open Banking nedeniyle rate limit zorunlu; UK Open Banking standardı saniyede 5 istek/TPP limiti getiriyor. Fintech sektöründe Stripe, Plaid, Adyen token bucket kullanıyor; tier bazında 100 RPS – 5.000 RPS aralığında. E-ticarette flash sale anlarında dinamik rate limit kritik; Shopify Plus’ın 2024 Black Friday verisi, dinamik rate limit ile altyapı maliyetini %38 azalttıklarını gösteriyor. Telekom sektöründe SMS API’leri için leaky bucket baskın; operatör gateway’lerinde stable throughput zorunlu. SaaS B2B ürünlerde plan bazında rate limit standart; Free tier 60 RPM, Pro 1.000 RPM, Enterprise sınırsız ama soft limit + alert pattern’i. IoT ve sanayi 4.0’da MQTT broker rate limit gerekli; HiveMQ engineering blogu 50.000 cihazlı flotta token bucket per-device ile p99 28 ms broker latency tuttuklarını raporluyor.
Kurumsal Rate Limiting Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Algoritma seçimi yapılmadan implementasyona başlanıyor; “Cloudflare/Kong default neyse o” diyerek sliding window log kullanılıyor, Redis maliyeti 3× artıyor.
- Per-user, per-IP, per-key arasındaki ayrım netleşmemiş; tek bir global limit konuluyor, NAT arkasındaki ofis ağları tek IP’den ortak limit yiyor, false positive %23 oluyor.
- 429 yanıtında Retry-After header’ı boş bırakılıyor; istemciler rastgele backoff yapıyor, “thundering herd” oluşuyor.
- Burst toleransı düşük tutulduğu için legitimate kullanıcılar reddediliyor; “Customer Support’a ‘API çalışmıyor’ ticketları geliyor”, root cause rate limit oluyor.
- Distributed rate limit consistency garantisi yanlış kuruluyor; Redis cluster split-brain anlarında çift sayım veya eksik sayım oluşuyor, eventual consistency ile race condition’lar prod’a sızıyor.
- Gözlemlenebilirlik eksik; 429 yanıtlarının top-N IP/API key bazında dağılımı dashboard’da yok, incident response’ta MTTR 38 dakikaya çıkıyor.
Sonuç
API rate limiting 2026’da SLO bütçesini ve maliyeti korumanın birinci aracı; saldırı önleme yan ürün. Token bucket public API’ler için en doğru genel-amaçlı seçim, leaky bucket sabit çıkış oranı gerekli işleme kuyruklarında, sliding window counter ise dengeli orta yol. Cloudflare 2024 ve Stripe engineering verileri birleştirildiğinde net pratik kararlar çıkıyor: kamu API’lerinde token bucket + sliding window counter hybrid, iç servislerde basit token bucket, kuyruk-tabanlı işlerde leaky bucket. Eylem planı: (1) algoritmayı senaryo bazında seçin, (2) Redis Lua script ile atomik counter implement edin, (3) RED method metriklerini Datadog/Prometheus’a verin, (4) plan bazında segment edilmiş limit politikası yazın, (5) 429 yanıtında Retry-After header’ını standart hale getirin. Yorumlarınızı bekliyorum.
Sıkça Sorulan Sorular
Token bucket ve leaky bucket arasındaki en önemli fark nedir?
Burst toleransı. Token bucket kovasında biriken token’lar kadar burst kabul ediyor; istemci 5 saniye sessiz kaldıysa ardından 5 RPS’lik anlık yoğunluk geçebiliyor. Leaky bucket ise sabit çıkış oranıyla sızıyor, hiç burst kabul etmiyor. Public API’ler için token bucket, traffic shaping için leaky bucket.
Sliding window log neden pahalı?
Her isteğin timestamp’i Redis sorted set’te saklanıyor, memory ihtiyacı O(N) — istek sayısı kadar. Ortalama bir API için sliding window counter’a göre 12× daha fazla memory tüketiyor, Redis cluster maliyeti aylık 4.800 dolar artıyor. Sadece hassasiyetin para etmesi gereken (örn. ödeme akışı) dar senaryolarda makul.
429 yanıtında ne yapmalıyım?
Retry-After header’ı saniye veya HTTP date formatında zorunlu. İstemcilere exponential backoff + jitter (rastgele kayma) eklemesini öneren dokümantasyon şart; Stripe, GitHub, AWS belgeleri bu pattern’i tanıtıyor. Body’de JSON ile retry_after, limit, remaining, reset alanları dönmeli.
Distributed rate limit nasıl tutarlı tutulur?
Redis cluster + Lua script ile atomik increment standart yaklaşım. Eventual consistency tolere edilebilir; %1-2 sapma kabul edilebilir trade-off. CRDT-tabanlı sayaçlar (örn. PN-Counter) bazı endüstride deneniyor ama operasyonel olgunluğu sınırlı. Stripe, Discord, Cloudflare hep Redis Lua kullanıyor.
Edge’de mi yoksa origin’de mi rate limit yapmalıyım?
İdeali ikisi de. Edge’de (Cloudflare/Fastly) volumetric ve scraping saldırılarını filtreliyorsunuz, p99 +1,4 ms ekleniyor. Origin’de business-logic rate limit (örn. plan bazlı) uyguluyorsunuz. Tek katmana güvenmek riskli; defense-in-depth yaklaşımı standart.
Ömer ÖNAL
Mayıs 18, 2026Rate limiting’i sadece kötü niyetli trafiğe karşı önlem sanmak hata; gerçek değeri SLO bütçesini ve maliyeti korumakta. Danışmanlık projelerinde gördüğüm tipik tablo: sliding window log şirketin Redis maliyetini ikiye katlıyor, token bucket aynı koruma seviyesini %30 daha az kaynakla sağlıyor. 2026’da doğru karar, algoritmayı segment bazında seçmek; kamu API’sinde sliding window counter, iç servislerde token bucket, kuyruk işlerinde leaky bucket. — Ömer ÖNAL