Rate Limiting Stratejileri: Token Bucket, Sliding Window ve API Koruma

API rate limiting nedir sorusunun kısa cevabı: belirli bir zaman penceresinde tek bir kullanıcının, IP’nin veya API anahtarının yapabileceği istek sayısını sınırlayan, hem servisi aşırı yüklenmeden hem de kötü niyetli trafikten koruyan bir trafik şekillendirme mekanizmasıdır. 2024 sonunda Cloudflare’in yayınladığı yıllık raporlara göre engellenen DDoS saldırılarının yaklaşık %37’si Layer 7 düzeyinde tek bir IP’den saniyede binlerce istek atan otomatik botlardan kaynaklandı; bu da rate limiting’in artık güvenlik duvarı kadar standart bir gereklilik haline geldiğini gösteriyor. Bu rehberde Token Bucket, Leaky Bucket, Fixed Window, Sliding Window Log ve Sliding Window Counter algoritmalarını mühendislik gerçekleriyle karşılaştırıyor; Cloudflare, AWS API Gateway, Kong ve Envoy gibi gateway’lerin yaklaşımlarını ölçülebilir metriklerle inceliyor; Redis tabanlı dağıtık limit tasarımının tuzaklarını çözüyoruz.

Rate limiting yalnızca “engelleme” değildir; kapasite planlaması, SLA garantisi ve multi-tenant sistemde adil paylaşım anlamına gelir. Stripe canlı API anahtarları için saniyede 100 okuma + 100 yazma tanımlar; test anahtarlarında bu rakam 25’tir. Stack Overflow 2024 Developer Survey’inde profesyonel geliştiricilerin %78’i en az bir public API’sinde rate limit uyguladığını belirtti. Bu yazı algoritma seçimini, idempotency-key tasarımını ve 429 Too Many Requests semantiğini hızlandıracak.

Görsel 1: Token bucket algoritmasının soyut bir görselleştirmesi; sabit hızda dolan kova ve istek başına tüketilen token akışı.

Rate Limiting Neden Sadece “Spam Engelleme” Değildir

Rate limiting’in tek amacı bot trafiğini durdurmak sanılır; bu eksik bir tanımdır. Üretim sistemlerinde rate limit dört katmana hizmet eder: maliyet kontrolü (downstream LLM API çağrısı tetikleniyorsa 10 yerine 1000 istek aylık faturayı 100 katına çıkarır), kapasite koruma (database connection pool 200’de patlıyorsa upstream’de 180 req/s’te kesmek pool’u korur), fair-use (free-tier kullanıcı premium kuyruğunu tıkamasın) ve compliance (GDPR, PCI-DSS denetimleri).

Cloudflare 2024 Q3 raporuna göre engellenen Layer 7 saldırılarının %71’i 1 Mpps altındaydı; yani klasik DDoS değil, uygulama mantığını sömüren yavaş ama sürekli saldırılardı. Bu trafiği yalnızca firewall durduramaz; çünkü “geçerli HTTP” gibi görünür. Burada token bucket veya sliding window devreye girer. API Güvenliği OWASP Top 10 2026 listesinde API4:2023 “Unrestricted Resource Consumption” maddesi doğrudan rate limit eksikliğini hedefler — yani limitsiz API açıkça OWASP riskidir.

İş hedefine göre rate limiting nedenleri

• Maliyet: OpenAI proxy yapan SaaS’larda kullanıcı başı günlük token kotası uygulamak (Cloudflare R2 + Workers KV ile saatte $0.005’a mal olur).
• Performans: p99 latency’i upstream sature olmadan tutmak; Envoy’un local_rate_limit filter’ı 1 ms’in altında karar verir.
• Güvenlik: Credential stuffing saldırılarında /login endpoint’inde 5 başarısız deneme / 15 dk pencere.
• Adil paylaşım: Multi-tenant SaaS’ta “noisy neighbor” sorununu engelleme — özellikle BFF Pattern Mikroservis mimarisinde shared backend için kritiktir.
• Compliance: Brute-force koruma maddesi olan PCI-DSS 8.3.6 ve NIST SP 800-63B.

Beş Klasik Algoritma: Token Bucket, Leaky Bucket, Fixed/Sliding Window

Rate limiting algoritmalarının seçimi “burst tolerance vs hafıza maliyeti vs hesaplama maliyeti” üçgeninde yapılır. Her algoritma aynı sonuca yaklaşır ama uçlarda davranış farklılaşır. Aşağıdaki tablo en çok kullanılan beş algoritmanın karşılaştırmasıdır.

Algoritma	Burst Toleransı	Hafıza/Kullanıcı	CPU Maliyeti	Uç Davranış
Token Bucket	Yüksek	~16 byte	O(1)	Trafik artışlarında esnek
Leaky Bucket (queue)	Yok (sabit hız)	~16 byte + queue	O(1)	Çıkışı düzleştirir, latency artırır
Fixed Window Counter	Çift kat (sınır)	~8 byte	O(1)	Pencere sınırında 2x burst riski
Sliding Window Log	Doğru	O(N) timestamp	O(N)	Hassas ama hafıza tüketir
Sliding Window Counter	Yaklaşık doğru	~24 byte	O(1)	Hibrit, en çok tercih edilen

Token Bucket: en yaygın tercih

Token bucket her kullanıcı için sabit kapasiteli (örneğin 100 token) bir kova düşünür ve bu kovayı sabit hızda (saniyede 10 token) doldurur. Her istek 1 token tüketir; kova boşsa 429 döner. Avantajı burst toleransı: kullanıcı 10 sn sessiz kalıp aniden 100 istek atabilir. AWS API Gateway ve Stripe token bucket varyantı kullanır; Stripe’ın dokümantasyonunda yüksek hızlı istemcilere “exponential backoff” önerilmesinin nedeni budur.

Leaky Bucket: trafiği düzleştir

Leaky bucket bir FIFO kuyruğudur; istekler içeri farklı hızlarda girer ama dışarı sabit hızda çıkar. Burst kullanıcıya yarar sağlamaz; fazla istekler beklemeye düşer. Avantaj: downstream sabit yük; database connection pool’unu korumak için idealdir. Dezavantaj: kuyrukta beklemek p99 latency’i artırır, kuyruk taşarsa istek düşer.

Fixed Window Counter: en basit, en riskli

“Saatte 1000 istek” derken pratikte yapılan Fixed Window’dur: anahtar, INCR, TTL=60s. Tek satır Redis. Sorunu büyüktür: pencere sınırında iki kat burst. Kullanıcı 12:00:59’da 1000, 12:01:00’da yine 1000 istek atar; sınır 1000 olmasına rağmen 2 saniyede 2000 istek backend’e ulaşır. İç API’ler için kabul edilebilir, müşteri-yüzlü API’ler için değil.

Sliding Window Log: doğru ama pahalı

Her isteğin timestamp’ini Redis ZSET’e yazar, ZREMRANGEBYSCORE ile pencere dışını siler, ZCARD ile sayar. Sonuç matematiksel olarak kesin. Maliyeti: O(istek_sayısı) hafıza. 1M aktif kullanıcı × dakikada 100 istek ≈ 9.6 GB. Sadece düşük trafikli kritik endpoint’lerde (/payments, /password-reset) tavsiye edilir.

Görsel 2: Sliding window counter algoritmasının zaman ekseninde iki pencere arasında ağırlıklı geçişi görselleştiren soyut diyagram.

Sliding Window Counter: pratiğin kazananı

Cloudflare’in referans hibrit yaklaşımı: iki ardışık fixed window sayacını tutar, kayan pencerede ağırlıklı ortalama hesaplar. Formül: count = current_window + previous_window * overlap_ratio. Hafıza ~24 byte, hesaplama O(1), uç hata oranı %0.003-%0.0003 arasında. Stripe, Cloudflare ve Discord production’da bunu kullanır. Pratikte “tek seçenek” olmasının nedeni Sliding Window Log doğruluğuna %99.9 yaklaşırken O(1) maliyetini koruması.

Dağıtık Rate Limiting: Redis ve Tutarlılık Tuzakları

Tek instance’lı backend’de rate limit kolaydır; in-memory map yeter. Sorun yatay ölçekleme ile başlar. 10 API node’unun her biri lokal sayaç tutarsa kullanıcı toplam 1000 istek yapar ama hedef “kullanıcı başına 100″dür. Çözüm merkezi state store: çoğunlukla Redis, bazen DynamoDB veya CRDT tabanlı sistemler.

Redis tabanlı sliding window counter’da klasik tuzak race condition‘dur. GET → check → INCR yaparsanız iki paralel istek limit altındayken her ikisi de geçer. Çözüm: Redis Lua scripti veya Redis 7+ FCALL. Atomik tek roundtrip; tipik p99 ~1.5 ms aynı bölgede, cross-region 30-80 ms. Cross-region rate limit yapmayın — bölgesel “anchored” tasarım (her bölge kendi quotasını yönetir, periyodik aggregator senkronize eder) tercih edilir.

Tutarlılık Modeli	Latency Etkisi	Hata Oranı	Uygunluk
Strict (sync Redis + Lua)	+1-3 ms p99	~%0	Payment, auth, write-heavy
Eventually consistent (regional anchor)	+0.2 ms p99	%3-7 over-limit	Read-heavy public API
Local + periodic sync	+0 ms p99	%10-20 over-limit	Free-tier, marketing API
CRDT (G-Counter)	+0.5 ms p99	%2-5 over-limit	Multi-region active-active

State store’un da kendi limit’i olduğunu unutmayın: Redis Cluster tek instance ~150k ops/sec yapar, ölçek artınca sharding gerekir. Bir başka konu: Saga Pattern tabanlı uzun işlemlerde rate limit “request başı” mı “iş başı” mı sayılır netleştirilmelidir. Yanlış sınıflama, asenkron retry trafiğinin limit’i tüketmesine yol açar.

Redis Lua scripti minimum şablonu

• Adım 1: KEYS[1] = “rl:{user_id}:{endpoint}”.
• Adım 2: ZREMRANGEBYSCORE pencere dışı eski timestamp’leri sil.
• Adım 3: ZCARD ile mevcut sayım.
• Adım 4: Limit altıysa ZADD + EXPIRE; üstündeyse {denied, retry_after} dön.
• Adım 5: Tek RTT’de tüm karar — atomik garanti.

API Gateway Karşılaştırması: Cloudflare, AWS, Kong, Envoy

“Rate limit kodda mı, gateway’de mi?” sorusunun cevabı genelde gateway’dir: limit business logic’ten önce gelmeli ki maliyetli işlem öncesi reddedilebilsin. Aşağıda yaygın gateway’lerin özellikleri karşılaştırılıyor. Rakamlar 2024-2025 resmi dokümantasyondan; gerçek performans iş yüküne göre değişebilir.

Gateway	Algoritma	Distribution	p99 Karar Latency	Tipik Maliyet
Cloudflare Rate Limiting	Sliding Window	Edge global	~8 ms (edge)	$5/M req üstünden
AWS API Gateway Usage Plans	Token Bucket	Bölgesel	~20 ms	$3.50/M req
Kong Rate-Limiting plugin	Tüm algoritmalar	Self-hosted	~1-2 ms	Sunucu maliyeti
Envoy local_rate_limit	Token Bucket	Service mesh	~0.3 ms	Sunucu maliyeti
NGINX limit_req	Leaky Bucket	Tek instance	~0.2 ms	Ücretsiz / Plus

Cloudflare Rate Limiting

Avantaj: Edge’de uygulandığı için kötü trafik origin’e ulaşmaz; 300+ POP’ta dağıtık counter. Dezavantaj: Edge counter eventually consistent — pencere başında %10-15 tolerance. Ne zaman seç: Public API, statik içerik koruması, tek katmanlı DDoS koruma. Edge Computing Cloudflare Workers üzerine kurulan servislerde Workers KV ile özel anahtar tabanlı limit yazılabilir.

AWS API Gateway Usage Plans

Avantaj: API Key başına quota + throttle ikili yapı, Lambda ile sıkı entegrasyon. Dezavantaj: Tek bölgede çalışır; multi-region için AWS WAF rate-based rules ek olarak gerekir. Ne zaman seç: AWS ekosisteminde, monetizasyonu API Key etrafında kurulmuş SaaS’lar.

Kong & Envoy: kontrol senin

Avantaj: Kong’un rate-limiting plugin’i 5 algoritmayı destekler, Redis backend ile dağıtık. Envoy global_rate_limit filter’ı RLS ile gRPC üzerinden çalışır; envoyproxy/ratelimit referans Redis tabanlıdır. Dezavantaj: Operasyonel yük; Redis cluster ve plugin yapılandırması ekibinizde olmalı. Ne zaman seç: Service Mesh Karşılaştırması sonrası Istio/Envoy kullanan ekipler.

Görsel 3: API gateway’in HTTP isteklerini sıraladığı, 429 reddedilen ve geçen istekleri filtreleyen soyut bir kapı/duvar görselleştirmesi.

HTTP 429 Semantiği ve Doğru Yanıt Tasarımı

RFC 6585 ile tanımlanan 429 Too Many Requests, rate limit aşımı için standart yanıttır. Pratikte ekiplerin yarısı 503 veya 403 döner; bu semantik olarak yanlıştır ve istemcinin doğru retry stratejisi izlemesini engeller. MDN 429 dokümantasyonu, Retry-After‘ın saniye veya HTTP-date olarak gönderilmesini açıkça belirtir.

İyi tasarlanmış 429 yanıtı şu alanları içerir: Retry-After (zorunlu), X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset ve gövdede insan-okunabilir mesaj. GitHub, Stripe, Twilio bu standart header set’ini benimser. IETF Draft “draft-polli-ratelimit-headers” 2024’te güncellendi ve yakında RFC olması bekleniyor.

Header	Anlam	Örnek Değer	Zorunluluk
Retry-After	Yeniden deneme süresi	30 (saniye)	RFC 6585 ZORUNLU
X-RateLimit-Limit	Pencere için toplam quota	1000	Önerilir
X-RateLimit-Remaining	Pencerede kalan istek	0	Önerilir
X-RateLimit-Reset	Pencere sıfırlanma zamanı	1716480000	Önerilir
RateLimit-Policy	Pencere ve birim açıklaması	1000;w=3600	IETF Draft

İstemci tarafında retry stratejisi

1. Exponential backoff: 1s, 2s, 4s, 8s … maksimum 60s.
2. Jitter: Sabit backoff’a +/- %20 rastgele varyans; “thundering herd” sorununu engeller.
3. Retry-After önceliği: Sunucu açıkça süre verdiyse exponential backoff’u değil sunucunun değerini izle.
4. Circuit breaker: 5 ardışık 429 sonrası 30s tamamen durdur, sonra “half-open” dene.
5. Idempotency-Key: Retry sırasında aynı işlem iki kez yapılmasın diye unique key gönder.

Maliyet ve Quota Modelleri: SaaS Karşılaştırması

Büyük API sağlayıcıların quota modelleri rate limit kararlarınızı şekillendirir; siz de onların müşterisi olabilirsiniz. Tablo 2024-2025 resmi dokümantasyondan derlendi; planlar değişebilir.

Servis	Free Tier Limit	Paid Tier Limit	Pencere	Quota Birimi
Stripe (live)	100 read/s, 100 write/s	Anlaşmalı yükseltme	1 sn	İstek
GitHub REST API	60 req/h (unauth)	5000 req/h (auth)	1 saat	İstek
OpenAI gpt-4o	Yok (paid only)	10k TPM tier-1 ve üzeri	1 dk	Token + req
Twilio Messaging	1 msg/sn	Markaya göre 100+ MPS	1 sn	Mesaj
AWS API Gateway	10k req/s (default)	Quota artırma talebi	1 sn (burst 5k)	İstek

Quota birimi “istek” değil olabilir: OpenAI token, Twilio mesaj, AWS S3 operasyon tipi. Kendi API’nizi tasarlarken iş anlamında neyin pahalı olduğunu seçin. Bir LLM-proxy SaaS için “istek başına” limit yetersizdir çünkü tek istek 100k token tüketebilir; token bucket burada gerçekten token tabanlı olur. API Entegrasyon REST GraphQL rehberinde değindiğimiz gibi GraphQL’de “query complexity score” tabanlı limitleme gizlenen maliyetleri açığa çıkarır.

Quota tasarımı sırasında dikkat edilecekler

• Pencere uzunluğu trade-off’u: Saniye = düşük burst toleransı, hassas; saat = yüksek burst, eşitsiz dağılım.
• Anahtar hiyerarşisi: IP < session < user_id < api_key < org_id. Üst seviyeli her zaman alt seviyeyi karşılar.
• Endpoint başına farklı limit: /search/* = 100 req/s, /payments/* = 5 req/s. Tek limit her zaman yanlıştır.
• Soft vs hard limit: Soft = uyarı header’ı + log, hard = 429. Çoğu plan soft limit sunmalıdır.
• Aşım sonrası fiyatlandırma: “Over-limit pricing” — Vercel ve Render gibi platformlar limit aşımında durdurmak yerine ücretlendirir.

Üretim Senaryoları: Hangi Durumda Hangi Strateji

Doğru algoritma seçimi senaryoya bağlıdır. Tablo üretim sistemlerinde gözlemlenen 6 senaryo için önerilen algoritma + gateway kombinasyonudur — bir karar matrisi niteliğinde; ekibinizin kısıtları farklı kombinasyon zorunlu kılabilir.

Senaryo	Önerilen Algoritma	Önerilen Katman	Anahtar Boyut
Public REST API (Stripe-tipi)	Sliding Window Counter	Edge + App	api_key
Login / brute-force koruma	Sliding Window Log	App	username + IP
Webhook fan-out	Leaky Bucket	App	destination_url
LLM proxy / billing	Token Bucket (token-as-token)	App	user_id, tokens=cost
Internal service-to-service	Envoy local_rate_limit	Sidecar	service_name
DDoS mitigation	Sliding Window + WAF	Edge	IP, ASN, ülke

Login endpoint için özel notlar

Login için “saniyede 1 deneme” yanlıştır; meşru kullanıcı şifre yanlış yazınca hemen tekrar dener. Doğru tasarım: ilk 3 deneme limit yok, 4-5. arası 5 sn delay, 6+ için username+IP başına 15 dk ban. Kademeli yaklaşım UX bozmaz, credential stuffing’i ekonomik olmaktan çıkarır. Zero Trust Mimari tasarımlarında bu mantık device fingerprint ve risk score ile birleştirilir.

LLM proxy: “request” değil “token” sayın

OpenAI veya Anthropic API’sini proxy’leyen bir SaaS yazıyorsanız “saniyede 10 istek” limiti hatalıdır: 10 isteğin her biri 100k token isteyebilir, faturanız patlar. Token bucket’ın “token”ı gerçekten LLM token’ı olur. 1k input + 500 output token bir GPT-4o çağrısı tahmini 0.005-0.010 USD’dir; aylık 1M kullanıcıya saatte 100k token verirseniz ~$36,000-$72,000 aralığında maliyet üretirsiniz.

Görsel 4: Çok katmanlı koruma mimarisi — edge rate limit, WAF kuralları ve uygulama katmanı limitlerinin birlikte oluşturduğu savunma diyagramı.

Observability: Limit Olmayan Limit Yoktur

Rate limit koymak yarı iştir; gözlemlemek diğer yarısıdır. Çoğu ekip 429 oranını “düşük olmalı” diye bilir ama hedef değeri sorulduğunda cevap veremez. Doğru hedef %0.1 ile %1 arası 429 oranıdır: %0 altında limit gereksizdir veya çok gevşektir; %5 üstü meşru kullanıcılar engelleniyordur. Bu metriği endpoint, müşteri segmenti ve coğrafya bazında ayrı izleyin.

Prometheus + Grafana kurulumunda izlenecek metrikler: rate_limit_decisions_total{decision="allow|deny"}, rate_limit_remaining_quota, rate_limit_redis_latency_seconds_bucket. Kubernetes Network Policy ile birleştirilmiş mimaride rate limit metrikleri sidecar’tan toplanır; service mesh control plane’de aggregated dashboard üretilir.

• Top denied users dashboard: En çok 429 alan 100 anahtar — bot mu, meşru mu ayrımı.
• Quota burn rate: Pencere ortasında %80’i tüketmiş kullanıcılar — proaktif uyarı.
• Per-endpoint heatmap: Saat bazında trafik patern’i — gerçek limit kalibrasyonu için.
• Geographical anomaly: Tek bir ülkeden ani 10x artış — coordinated attack işareti.

Anti-Pattern’ler: Yapılan Yaygın Hatalar

Rate limit projeleri algoritma seçiminde değil, yanlış varsayımlarda batar. Mühendis ekiplerinin en yaygın 7 hatası; her biri en az bir canlı incident’a yol açmıştır.

1. “IP başına” limit, NAT’lı şirketlerde: Tek IP arkasında 5000 çalışan olabilir; kurumsal müşteriniz tek tıkla sizden bloklanır. Çözüm: IP + user_agent + session_id kombinasyonu.
2. Tek üst-seviye limit: “1000 req/s” derken /search vs /payment ayrımı yapmamak; pahalı endpoint ucuz endpoint trafiğiyle ölür.
3. Localhost / internal IP’leri unutmak: Sağlık check’leri ve internal service çağrıları limit’e takılır; allowlist gerekir.
4. Yanlış pencere boyutu: 1 saatlik pencere ortasında bayram trafiği gelince ne sınırlıyorsun belirsizleşir; Hexagonal Architecture gibi test-edilebilir bir tasarımda limit pencereleri load testle kalibre edilmeli.
5. Retry-After göndermeden 429 dönmek: İstemci ne zaman tekrar deneyeceğini bilmez, agresif retry’a girer.
6. Soft limit yokluğu: Kullanıcı sınırı bilmeden çarpar; tipik UX katliamı. X-RateLimit-Remaining header’ı şart.
7. Çoklu retry layer’ı: İstemci 5 kez retry yapıyor, gateway 3 kez retry yapıyor, internal SDK 2 kez yapıyor → tek mantıksal istek 30 fiziksel istek üretir, sistem kendi kendini DDoS eder.

Bu liste, üretim mimarisi değerlendirmelerinde Ömer Önal danışmanlığında en sık karşılaşılan bulguları yansıtır. Mikroservis Mimarisi geçişinde özellikle 7. madde (çoklu retry layer’ı) ekiplerin radar dışında kalır ve insidentlarda asıl sebep olur.

Sıkça Sorulan Sorular (SSS)

Sonuç

Rate limiting bir yapım kararı değil mimari disiplindir: doğru algoritma (çoğunlukla Sliding Window Counter veya Token Bucket), doğru katman (mümkünse edge + uygulama çift katman), doğru anahtar (api_key > user_id > IP) ve doğru observability (%0.1-%1 hedef 429 oranı) bir araya geldiğinde sistem kötü trafiğe ve meşru kullanıcılara karşı dengeli kalır. Token Bucket’ın esnekliği ve Sliding Window Counter’ın hassasiyeti üretim ekiplerinin %90’ında yeterli kapsamı sunar; geri kalan senaryolar Leaky Bucket veya token tabanlı sayımla çözülür.

Karar çerçevesi: önce iş ihtiyacını tanımla (maliyet, kapasite, güvenlik); anahtar hiyerarşisini çiz; gateway’i seç (Cloudflare edge için, Envoy iç servis için); en son algoritma seçilir — algoritmalar arası fark gateway’in sunduğuyla sınırlıdır. Modular Monolith mimarisinde limit modül sınırında uygulanır; mikroservislerde sidecar düzeyinde. Bu mimari karar limit tasarımını şekillendirir.

Kurumsal API’ler için rate limit + WAF + observability üçlüsünün entegrasyonunda destek almak isterseniz omeronal.com/iletisim üzerinden iletişime geçebilirsiniz. Anti-pattern’leri raporlayan kısa bir teknik audit ile başlayan süreç çoğu ekipte ilk ayda 429 oranını hedef bant aralığına çeker.