REST API'ler, yüksek trafik altında kaynakların aşırı kullanımını engellemek için rate limiting (oran sınırlama) mekanizmalarına ihtiyaç duyar. Hangi algoritmanın seçileceği, uygulamanın performansını, kullanıcı deneyimini ve güvenliğini doğrudan etkiler. Bu yazıda, en popüler iki strateji olan Token Bucket ve Sliding Window yaklaşımlarını karşılaştırıyor, artılarını ve eksilerini somut örneklerle ele alıyoruz.
Token Bucket Algoritması Nedir?
Token Bucket, bir kova içindeki token'ların periyodik olarak doldurulması temeline dayanır. Her istek bir token tüketir; token biterse istek reddedilir veya kuyruğa alınır. Bu algoritma, bursty (ani yükselmeli) trafiklere izin vermesiyle bilinir. Örneğin, dakikada 100 istek limiti ve 20 token kapasiteli bir kova ile kullanıcı kısa süre içinde 20 istek gönderebilir, ardından token'lar yenilenene kadar bekler.
Token Bucket, özellikle mikroservislerde API Gateway deseni ile birlikte sıkça tercih edilir. API Gateway, merkezi bir noktada rate limiting uygulamak için idealdir; token bucket'ın basit yapısı dağıtık senaryolarda kolay implementasyon sağlar.
Token Bucket'ın Avantajları
- Burst trafik desteği: Kullanıcıların kısa süreli ani yüklerini tolere eder.
- Basit uygulama: Bellekte sadece kova boyutu ve son doldurma zamanı gibi iki değer tutulur.
- Esneklik: Farklı kullanıcılar için farklı kova boyutları ve doldurma hızları atanabilir.
Token Bucket'ın Dezavantajları
- Uzun süreli düşük kullanımda birikim: Kullanıcı token biriktirirse, anlık büyük bir yük oluşturabilir.
- İstikrarlılık sorunu: Token'lar sürekli kullanılmazsa, limit sanki aşılmış gibi davranabilir.
Sliding Window Algoritması Nedir?
Sliding Window, zamanı sabit pencerelere bölmek yerine, her isteğin zaman damgasını kullanarak kayan bir pencere hesaplar. Bu sayede, bir dakikalık pencere içindeki istek sayısı gerçek zamanlı olarak izlenir. Örneğin, 10:15:30 ile 10:16:30 arasındaki istekler sayılır. Bu yöntem, limitin kesin bir zaman aralığında aşılmamasını sağlar.
Sliding Window, özellikle REST API versiyonlama stratejileri ile birlikte kullanıldığında, farklı versiyonlara farklı limitler atamak için uygun bir yapı sunar. Token Bucket'a kıyasla daha adil bir dağıtım sağlar.
Sliding Window'ın Avantajları
- Adil limit: Ani yüklerde bile limit aşımı olmaz, istekler düzgün dağılır.
- Kesinlik: Gerçek zamanlı pencere ile limit ihlali tespiti daha hassastır.
- Kullanıcı dostu: Kullanıcılar limiti aştığında net bir bekleme süresi verebilir (örneğin "3 saniye sonra tekrar deneyin").
Sliding Window'ın Dezavantajları
- Daha yüksek bellek kullanımı: Her isteğin zaman damgası saklanırsa, özellikle yüksek trafikte hafıza artar.
- Karmaşık implementasyon: Token Bucket'a göre kodlaması daha zordur; zaman damgalarını yönetmek gerekir.
- Dağıtık ortamda senkronizasyon: Farklı sunucularda pencere bilgisi paylaşılmalıdır.
Detaylı Karşılaştırma Tablosu
| Özellik | Token Bucket | Sliding Window |
|---|---|---|
| Temel Mantık | Periyodik token doldurma | Zaman damgasına dayalı sayma |
| Burst Trafik | İzin verir (kova kapasitesi kadar) | Sınırlandırır (pencere boyutuna göre) |
| Bellek Kullanımı | Düşük (sabit 2 değişken) | Orta/Yüksek (isteğe bağlı log tutma) |
| Adillik | Düşük (token birikimi) | Yüksek (gerçek zamanlı) |
| Uygulama Karmaşıklığı | Basit | Orta |
| Dağıtık Senkronizasyon | Kolay (merkezi token yöneticisi) | Zor (paylaşılan zaman bilgisi) |
| Kesin Limit Aşımı Tespiti | Yaklaşık | Kesin |
Hangi Senaryoda Hangi Algoritma Seçilmeli?
Seçim, API'nizin trafik desenine ve iş gereksinimlerine bağlıdır. Aşağıdaki durumları göz önünde bulundurun:
- Burst trafiğe ihtiyaç duyan uygulamalar (örn. medya streaming, dosya yükleme): Token Bucket, kullanıcıların kısa süreli yüksek taleplerini karşılamak için daha uygundur.
- Adil kullanım ve stabil performans gerektiren senaryolar (örn. finans API'leri, gerçek zamanlı veri): Sliding Window, limitlerin aşılmamasını garanti eder.
- Basit ve hızlı implementasyon arıyorsanız: Token Bucket, daha az kodla çalışır.
- Dağıtık bir sistemde merkezi bir rate limiter kullanıyorsanız: Sliding Window'ın senkronizasyon karmaşıklığı artar; bu durumda Token Bucket veya Redis tabanlı sliding window log daha uygun olabilir.
Ayrıca, Mobil Uygulamalarda OAuth 2.0 ve PKCE gibi güvenlik odaklı projelerde, token yenileme istekleri için ayrı rate limiting stratejileri belirlemek gerekir. Örneğin, token endpoint'ine yapılan isteklerde daha sıkı bir sliding window tercih edilebilir.
Yaygın Hatalar ve Dikkat Edilmesi Gerekenler
- Limitleri çok düşük ayarlamak: Kullanıcı deneyimini bozar; gerçek trafik analizi yaparak başlayın.
- Rate limiting'i tek başına yeterli görmek: Cursor-based pagination gibi optimizasyonlarla birleştirerek istek sayısını azaltmak daha etkilidir.
- Token bucket için kova boyutunu yanlış seçmek: Çok büyük kova, burst'un sistemi çökertmesine yol açabilir; çok küçük kova ise kullanıcıları gereksiz yere sınırlar.
- Sliding window'da pencerenin asenkron hesaplanması: Yanlış uygulama, sonuçların tutarsız olmasına neden olur; mutlaka atomik işlemler kullanın.
Uygulamalı İpucu: Basit Bir Token Bucket Implementasyonu (Node.js)
class TokenBucket {
constructor(capacity, refillRate) {
this.capacity = capacity;
this.tokens = capacity;
this.refillRate = refillRate; // token per saniye
this.lastRefill = Date.now();
}
consume(tokens = 1) {
this._refill();
if (this.tokens >= tokens) {
this.tokens -= tokens;
return true;
}
return false;
}
_refill() {
const now = Date.now();
const elapsed = (now - this.lastRefill) / 1000;
this.tokens = Math.min(this.capacity, this.tokens + elapsed * this.refillRate);
this.lastRefill = now;
}
}Bu basit sınıf, Redis gibi dağıtık bir cache ile birleştirilerek production'da kullanılabilir. Sliding window implementasyonu ise genellikle bir zaman damgası listesi veya Redis'te sorted set ile yapılır.
Sonuç olarak, her iki algoritma da REST API'ler için etkili rate limiting çözümleridir. Token Bucket, burst trafiğe ihtiyaç duyan ve basitliği seven ekipler için; Sliding Window ise adil ve kesin limitler isteyen yüksek trafikli sistemler için daha uygundur. Projenizin ihtiyaçlarını değerlendirin, test edin ve en uygun stratejiyi seçin.
Sık Sorulan Sorular
Rate limiting neden gereklidir?
Rate limiting, bir API'ye belirli bir zaman diliminde yapılabilecek istek sayısını sınırlayarak aşırı kullanımı, DDoS saldırılarını ve kaynak tükenmesini önler. Ayrıca adil kullanım sağlar ve sistem performansını korur.
Token bucket ile sliding window arasındaki temel fark nedir?
Token bucket, periyodik token doldurma ile çalışır ve ani yüklenmelere izin verir. Sliding window ise kayan bir zaman penceresi kullanarak istekleri sayar ve daha adil bir limit uygular.
Hangi durumda token bucket tercih edilmelidir?
Token bucket, kullanıcıların kısa süreli yoğun isteklerine izin vermek istendiğinde (örneğin medya yükleme veya veri senkronizasyonu) idealdir. Ayrıca uygulaması basittir ve düşük bellek kullanır.
Sliding window hangi senaryolarda daha başarılıdır?
Sliding window, limitlerin kesin olarak aşılmaması gereken ve sürekli stabil trafik istenen uygulamalarda (örneğin finans API'leri veya gerçek zamanlı veri akışı) daha başarılıdır.
Rate limiting implementasyonunda dikkat edilmesi gereken en önemli nokta nedir?
Limit değerlerini doğru ayarlamak ve dağıtık sistemlerde senkronizasyonu sağlamak kritiktir. Ayrıca rate limiting'i tek başına değil, API optimizasyonlarıyla (örneğin pagination) birlikte kullanmak daha etkilidir.
