REST API'lerde rate limiting, bir istemcinin belirli bir zaman aralığında gönderebileceği istek sayısını sınırlayarak sunucu kaynaklarını korur ve hizmet kalitesini garanti altına alır. Fixed Window ve Token Bucket, en yaygın kullanılan iki algoritmadır. Bu yazıda, her iki algoritmayı karşılaştırarak API'nizin ihtiyaçlarına en uygun olanı seçmenize yardımcı olacağız.
Fixed Window Algoritması Nedir?
Fixed Window (Sabit Pencere) algoritması, zamanı eşit aralıklara böler ve her pencerede belirli sayıda isteğe izin verir. Örneğin, dakikada 100 istek limiti varsa, saat başı ve 60. saniyede pencere sıfırlanır. Bu basit yöntem, uygulaması kolay ve hafıza kullanımı düşük olduğu için küçük ölçekli sistemlerde tercih edilir.
Ancak belirgin bir dezavantajı vardır: Trafik patlaması. Pencere sınırında biriken istekler, yeni pencerenin başında heapsize kullanıcı tarafından gönderilirse sistem anlık yük altında kalabilir. Örneğin, 100 istek/dakika limitinde kullanıcı 59. saniyede 100 istek, 61. saniyede tekrar 100 istek gönderebilir; bu da ortalamada saniyede 3.33 istek yerine 200 istek/2 dakika gibi bir dağılım yaratır.
Token Bucket Algoritması Nedir?
Token Bucket (Jeton Kutusu), sabit oranda jeton üreten ve her istekte bir jeton tüketen bir algoritmadır. Kova maksimum kapasiteye sahiptir, dolu olduğunda yeni jetonlar atılır. Bu sayede trafik patlamalarını yumuşatır ve ortalama hızı sınarken kısa süreli ani yüklere izin verir. Örneğin, saniyede 10 jeton ekleniyor ve kova boyutu 20 ise kullanıcı 2 saniyelik birikimle aynı anda 20 istek gönderebilir, ancak devamında hız düşer.
Token Bucket, özellikle değişken trafik profiline sahip uygulamalar (video akışı, anlık mesajlaşma) için idealdir. Amazon AWS API Gateway ve Stripe gibi büyük hizmetler bu algoritmayı kullanır.
Karşılaştırma Tablosu
| Özellik | Fixed Window | Token Bucket |
|---|---|---|
| Uygulama Kolaylığı | Çok kolay, sayaç ve zaman damgası yeterli | Orta, kova durumu yönetimi gerekir |
| Bellek Kullanımı | Düşük (kullanıcı başına bir sayaç) | Orta (kova boyutu ve jeton miktarı saklanır) |
| Trafik Patlamaları | Sınırlarda patlama riski yüksek | Patlamaları kontrollü olarak emer |
| Ortalama Hız Tutarlılığı | Pencere bazında sabit, anlık değişken | Uzun vadede sabit, kısa vadede esnek |
| Dağıtık Sistem Desteği | Zor (zaman senkronizasyonu gerekir) | Kolay (merkezi kova veya Redis) |
| Popüler Kullanım Örneği | Nginx limit_req_modülü | AWS API Gateway, Stripe |
Hangi Durumda Hangisini Seçmeli?
Fixed Window Tercih Edilecek Senaryolar
- Basit, tek sunuculu uygulamalar
- Kullanıcı sayısı az ve trafik düzenliyse
- Hızlı prototipleme ve minimal işlem süresi gerekiyorsa
Token Bucket Tercih Edilecek Senaryolar
- Değişken ve öngörülemez trafik (spike'lar sık)
- Dağıtık veya mikroservis mimarisi
- Kullanıcı deneyimi için anlık patlamalara izin vermek isteniyorsa
- Rate limiting'in API anahtarı bazlı değil, kullanıcı bazlı olması
Uygulama İpuçları ve Sık Yapılan Hatalar
Rate limiting uygularken dikkat edilmesi gereken bazı noktalar var:
- Kullanıcıyı bilgilendirin: 429 Too Many Requests yanıtıyla birlikte Retry-After başlığı ekleyin. Token Bucket'ta kalan jeton sayısını
X-RateLimit-Remainingile belirtin. - Aşırı keskin limitlerden kaçının: Fixed Window'un sınır patlaması sorununu çözmek için Sliding Window Log veya Sliding Window Counter gibi gelişmiş varyantlarını tercih edin.
- Dağıtık sistemlerde Redis kullanın: Token Bucket durumunu atomik komutlarla (INCR, EXPIRE) Redis'te tutmak hem tutarlılık sağlar hem de performansı artırır.
- Limiti yanlış yerde uygulamayın: Rate limiting genellikle API Gateway veya yük dengeleyici seviyesinde yapılmalı, uygulama katmanına bırakılmamalıdır.
Gerçek Hayat Örneği: Express.js ile Token Bucket
Aşağıda Node.js Express uygulamasında temel bir Token Bucket middleware'i yer alıyor. Bu örnek, kullanıcı bazında IP ile limit uygular:
const rateLimit = require('express-rate-limit');
const limiter = rateLimit({
windowMs: 60 * 1000, // 1 dakika
max: 100, // limit
message: 'Çok fazla istek gönderdiniz, lütfen daha sonra tekrar deneyin.'
});
app.use('/api', limiter);
Not: express-rate-limit varsayılan olarak Fixed Window kullanır. Token Bucket için özel bir implementasyon veya rate-limiter-flexible kütüphanesi tercih edilebilir.
Sonuç
Fixed Window ve Token Bucket arasındaki seçim, API'nizin trafik karakteristiğine ve ölçeklenebilirlik gereksinimlerine bağlıdır. Basit ve düşük yüklü sistemler için Fixed Window yeterli olabilirken, büyük ölçekli ve değişken trafiği olan API'ler için Token Bucket daha esnek ve güvenilir bir çözüm sunar. Hangi algoritmayı seçerseniz seçin, JWT token yönetimi ve input validation gibi diğer güvenlik önlemleriyle API'nizi sağlamlaştırmayı unutmayın. Ayrıca GraphQL vs REST karşılaştırmamızda da farklı API tasarım yaklaşımlarını inceleyebilirsiniz.
Rate limiting algoritması seçerken, uygulamanızın yük testlerini gerçek trafik senaryolarıyla yapmayı ve kullanıcı geri bildirimlerini dikkate almayı ihmal etmeyin.
Sık Sorulan Sorular
Fixed Window algoritmasının en büyük dezavantajı nedir?
Trafik patlamalarıdır. Pencere sınırında biriken istekler yeni pencere başlangıcında yoğunlaşarak sunucuda ani yük oluşturabilir.
Token Bucket algoritması neden daha esnektir?
Kova boyutu sayesinde kısa süreli patlamalara izin verirken uzun vadede ortalama hızı sınırlar. Bu, değişken trafik profiline sahip uygulamalar için idealdir.
Rate limiting için hangi HTTP durum kodu kullanılır?
Rate limit aşıldığında sunucu 429 Too Many Requests durum kodunu döndürür ve genellikle Retry-After başlığı ile ne kadar beklenmesi gerektiğini belirtir.
Dağıtık sistemlerde rate limiting nasıl uygulanmalı?
Merkezi bir veri deposu (örneğin Redis) kullanılarak tüm sunucular arasında durum paylaşılır. Atomik komutlar ve Lua scriptleri ile tutarlılık sağlanır.
Sliding Window ile Fixed Window arasındaki fark nedir?
Sliding Window, sabit pencere yerine kayan bir zaman aralığı kullanarak trafik patlamalarını önler. Daha karmaşıktır ancak daha adil bir kullanım sağlar.
