Token Bucket ve Sliding Window Rate Limiting Arasındaki Fark Nedir?

Token Bucket ve Sliding Window rate limiting algoritmaları, modern yazılım mimarilerinde kaynakların verimli kullanılmasını sağlayan ve sistem bütünlüğünü koruyan iki temel mekanizmadır. API uç noktalarının aşırı yüklenmesini engellemek, DDoS saldırılarını sınırlamak ve üçüncü taraf entegrasyon maliyetlerini kontrol altında tutmak isteyen teknik karar vericiler için doğru algoritma seçimi kritik bir öneme sahiptir. Bu analizde, Token Bucket algoritmasının anlık trafik (burst) toleransını ve Sliding Window algoritmasının keskin sınır koruma yeteneklerini mimari, bellek tüketimi, dağıtık sistem dinamikleri ve operasyonel maliyetler üzerinden detaylandırıyoruz.

Hız Sınırlandırma (Rate Limiting) Neden Kritik Bir Sistem Gereksinimidir?

Kontrolsüz Trafiğin Yol Açtığı Hizmet Kesintileri | Güvenlik Riskleri ve DDoS Koruması

Modern web servislerinde kontrolsüz trafik akışı, altyapının en zayıf halkasından kırılmasına yol açan bir domino etkisi tetikler. Bir API uç noktasına gelen eşzamanlı isteklerin kontrolsüzce artması, öncelikle veritabanı bağlantı havuzlarının (connection pools) tükenmesine, ardından uygulama sunucularının CPU ve bellek limitlerine ulaşarak yanıt veremez hale gelmesine neden olur. Kaskat (cascading) kesintiler olarak adlandırılan bu durum, sadece ilgili mikroservisin değil, ona bağımlı olan tüm ekosistemin çökmesiyle sonuçlanabilir. Özellikle veritabanı katmanında meydana gelen kilitlenmeler, sistemin kendi kendini toparlamasını zorlaştırır ve manuel müdahale gerektiren uzun süreli hizmet kesintilerine (downtime) yol açar.

Güvenlik perspektifinden bakıldığında, hız sınırlandırma (rate limiting) doğrudan bir savunma kalkanıdır. Dağıtık Hizmet Engelleme (DDoS) saldırıları, kaba kuvvet (brute-force) girişimleri ve kimlik bilgisi doldurma (credential stuffing) gibi siber tehditler, sistemlerin kaynak limitlerini zorlamayı hedefler. OWASP API Security Top 10 listesinde "API4:2023 - Unrestricted Resource Consumption" (Sınırsız Kaynak Tüketimi) başlığı altında incelenen bu risk, saldırganların API uç noktalarını aşırı kaynak tüketecek şekilde manipüle etmesini açıklar. Etkin bir hız sınırlandırma politikası bulunmayan sistemler, hem operasyonel olarak savunmasız kalır hem de bulut sağlayıcılarından gelen kontrol dışı faturalarla karşı karşıya kalır.

Veri gizliliği ve yasal uyumluluk çerçevesinde (KVKK, GDPR ve HIPAA gibi), kullanıcı verilerinin bulunduğu uç noktaların korunması yasal bir zorunluluktur. Saldırganların otomatik scriptler kullanarak kullanıcı profillerini veya hassas verileri kazıması (data scraping), veri ihlali olarak kabul edilir. Hız sınırlandırma, bu tür otomatize tarama faaliyetlerini engelleyerek veri sızıntılarının önüne geçer. Dolayısıyla, hız sınırlandırma yalnızca bir performans optimizasyon aracı değil; sistem kararlılığı, siber güvenlik, maliyet yönetimi ve yasal uyumluluk zincirinin en kritik halkalarından biridir.

Token Bucket Algoritması: İşleyişi ve Operasyonel Riskleri

Token Bucket Mekanizması Nasıl Çalışır? | Avantajı: Anlık Trafik (Burst) Artışlarına Tolerans | Dikkat Edilmesi Gerekenler: Kova Taşması ve Sınır İhlali Riskleri

Token Bucket algoritması, sabit bir hacme sahip sanal bir kovanın (bucket) belirli bir hızda jetonlar (tokens) ile doldurulması prensibine dayanır. Kova en fazla tanımlanan maksimum kapasite ($B$) kadar jeton barındırabilir. Sisteme gelen her bir istek (request), kovadan bir veya daha fazla jeton tüketir. Eğer kovada yeterli miktarda jeton varsa, istek kabul edilir ve jeton kovadan düşülür. Kovada jeton kalmadığında ise gelen yeni istekler doğrudan reddedilir (HTTP 429 Too Many Requests) veya bir kuyruğa alınarak bekletilir. Jetonlar, zaman diliminden bağımsız olarak, saniye veya dakika başına $r$ hızıyla (refill rate) kovaya sürekli olarak eklenir. Eğer kova tamamen doluysa, yeni üretilen jetonlar dışarı taşar ve yok sayılır.

Bu algoritmanın en belirgin avantajı, anlık trafik artışlarına (burst traffic) izin vermesidir. Sistem sakin bir dönem geçirdiğinde, kova tamamen jetonla dolar. Ani bir trafik dalgası geldiğinde, kova kapasitesi ($B$) kadar istek aynı anda, hiçbir gecikmeye uğramadan işlenebilir. Bu esneklik, özellikle kullanıcıların sayfa yükleme esnasında aynı anda birden fazla statik ve dinamik istek gönderdiği web uygulamalarında kullanıcı deneyimini korur. Örneğin, bir web sayfası açılırken tarayıcının attığı 15 eşzamanlı API isteği, Token Bucket sayesinde engellenmeden hızlıca çözümlenir.

Ancak bu esneklik, beraberinde operasyonel riskler de getirir. Eğer kova kapasitesi ($B$) çok yüksek ayarlanırsa, ani trafik patlamaları veritabanı veya alt servisler üzerinde aşırı yük oluşturabilir. Kova hacminin ve jeton yenilenme hızının yanlış yapılandırılması, sınır ihlallerine ve downstream servislerin çökmesine neden olabilir. Özellikle dağıtık mimarilerde, kovadaki jeton miktarının senkronize edilmesi (örneğin Redis üzerinde bir anahtarın güncellenmesi) kilitlenme (lock contention) ve yarış durumlarına (race conditions) yol açabilir. Bu nedenle Token Bucket uygulanırken, kova kapasitesinin downstream sistemlerin maksimum taşıma kapasitesiyle doğrudan uyumlu olacak şekilde hesaplanması zorunludur.

Sliding Window Algoritması: İşleyişi ve Operasyonel Riskleri

Zaman Dilimi Kaydırma (Sliding Window) Mekanizması Nasıl Çalışır? | Avantajı: Keskin Sınır İhlallerinin Pürüzsüzce Engellenmesi | Dikkat Edilmesi Gerekenler: Bellek Tüketimi ve Performans Yükü

Sliding Window algoritması, zamanı sabit pencerelere bölmek yerine, her bir isteğin geldiği andan geriye doğru dinamik bir zaman penceresi (window) hesaplayarak çalışır. Bu algoritma temelde iki farklı yaklaşımla uygulanır: Sliding Window Log ve Sliding Window Counter. Sliding Window Log yaklaşımında, her bir kullanıcının yaptığı isteklerin zaman damgaları (timestamp) bir veri yapısında (genellikle Redis Sorted Set) saklanır. Yeni bir istek geldiğinde, mevcut zamandan belirlenen pencere süresi (örneğin 60 saniye) çıkarılarak pencere dışı kalan eski zaman damgaları bellekten silinir. Kalan zaman damgalarının sayısı, izin verilen maksimum istek limitinden küçükse istek kabul edilir ve yeni zaman damgası listeye eklenir.

Sliding Window Counter ise bu bellek yoğun log tutma işlemini optimize etmek için önceki sabit pencerenin istek sayısını ve mevcut pencerenin geçen süre oranını kullanarak matematiksel bir tahminleme yapar. Örneğin limit dakikada 100 istek ise ve şu anki dakikanın 18. saniyesindeysek (dakikanın %30'u), algoritma bir önceki dakikadaki istek sayısının %70'ini mevcut dakikadaki istek sayısıyla toplar. Elde edilen değer limitin altındaysa istek onaylanır. Bu hibrit yaklaşım, hem Fixed Window algoritmasının pencerelerin kesişim noktalarında sınırın iki katına kadar istek sızdırma (double limit) hatasını çözer hem de bellek tüketimini minimize eder.

Zaman Ekseni (Saniye):
[0] ---------------------- [30] ---------------------- [60] ---------------------- [90]
             |                    | (Mevcut İstek)             |
             |<------- Dinamik Zaman Penceresi (60 Saniye) --->|

Sliding Window algoritmasının en büyük avantajı, sınır ihlallerini pürüzsüzce engellemesidir. Fixed Window algoritmalarındaki gibi pencere sınırlarında oluşan yapay trafik yığılmaları (bursting at window boundaries) bu yöntemde yaşanmaz. Sistem, her an için belirlenen limitin aşılmayacağını garanti eder. Ancak, özellikle Sliding Window Log uygulamalarında ciddi bir bellek tüketimi (memory footprint) ve performans yükü söz konusudur. Her bir istek için ayrı bir zaman damgası tutulması, yüksek trafikli sistemlerde bellek kullanımının $O(N)$ karmaşıklığıyla (burada $N$ istek sayısıdır) dikey olarak büyümesine yol açar. Bu durum, veri tabanı ve önbellek (cache) maliyetlerini doğrudan artırarak sistem mimarlarını Sliding Window Counter gibi daha az hassas ama daha ekonomik yaklaşımlara yönlendirir.

Doğrudan Karşılaştırma: Token Bucket vs. Sliding Window

Trafik Şekillendirme ve Esneklik Farkları | Bellek (Memory) ve Kaynak Kullanımı Karşılaştırması | Dağıtık Sistemlerde (Distributed Systems) Uygulanabilirlik

Token Bucket ve Sliding Window algoritmaları arasındaki temel ayrım, trafiği şekillendirme (traffic shaping) biçimlerinde ve sistem kaynaklarını tüketme modellerinde yatmaktadır. Token Bucket, doğası gereği anlık trafik artışlarına (burst) tolerans gösterir. Bu özellik, API istemcisinin kısa sürede çok sayıda istek atıp ardından uzun süre sessiz kalacağı senaryolar için mükemmel bir esneklik sunar. Diğer taraftan Sliding Window, trafiğin zamana olabildiğince homojen dağılmasını hedefler. Sınırları dinamik olarak kaydırdığı için, belirlenen periyot içinde hiçbir zaman limit değerinin (örneğin dakikada 100 istek) üzerine çıkılmasına izin vermez.

Bellek ve CPU kaynaklarının kullanımı açısından Token Bucket oldukça hafiftir. Algoritma, her kullanıcı veya IP adresi için yalnızca iki temel veriyi saklar: son jeton güncellenme zamanı (timestamp) ve mevcut jeton sayısı. Yeni bir istek geldiğinde, arka planda sürekli çalışan bir zamanlayıcıya (timer thread) ihtiyaç duymadan, geçen zaman formülize edilerek yeni jeton sayısı hesaplanır. Bu sayede bellek tüketimi kullanıcı başına $O(1)$ düzeyinde kalır. Sliding Window Log ise her isteği bellekte tek tek tuttuğu için milyonlarca aktif kullanıcısı olan bir sistemde Redis veya Memcached üzerinde devasa veri boyutlarına ulaşabilir. Bu maliyeti azaltmak amacıyla tercih edilen Sliding Window Counter ise Token Bucket ile benzer şekilde düşük bellek tüketimine sahiptir ancak matematiksel bir tahminleme kullandığı için %0.01 ile %0.05 oranında hassasiyet sapmalarına yol açabilir.

Dağıtık sistemlerde (distributed systems) her iki algoritmanın da ölçeklenebilirlik zorlukları vardır. Çoklu sunucu gruplarının (server clusters) arkasında çalışan bir API gateway katmanında, isteklerin hangi sunucuya gideceği belirsizdir. Bu durum, rate limiting durumunun (state) merkezi bir önbellek deposunda (örneğin Redis) tutulmasını zorunlu kılar. Token Bucket, Redis üzerinde atomik işlemler yürüten Lua scriptleri aracılığıyla yarış durumları (race conditions) yaşanmadan son derece hızlı bir şekilde çalıştırılabilir. Sliding Window Log ise Redis'in Sorted Set veri yapısı üzerindeki @@CODE0@@ ve @@CODE1@@ komutlarını pipeline halinde çalıştırarak uygulanır. Ancak bu işlem, yüksek eşzamanlılık (high concurrency) altında ağ gecikmelerine (network round-trip time) ve kilitlenmelere daha duyarlıdır. Ayrıca, dağıtık sistemlerdeki sunucuların saat senkronizasyonu (NTP drift) Sliding Window zaman penceresi hesaplamalarında küçük sapmalara yol açabilir.

Mimariniz İçin Hangi Algoritmayı Seçmelisiniz?

Esneklik ve Maliyet Odaklı Yaklaşımlar | Katı Limitler ve Hassas API'ler İçin Öneriler

Algoritma seçimi yaparken, öncelikle iş modelinizin ve korumak istediğiniz sistemlerin karakteristik özelliklerini analiz etmeniz gerekir. Eğer kullanıcı deneyiminin kesintiye uğramaması birinci önceliğinizse ve sisteminiz geçici trafik dalgalanmalarını (bursting) kaldırabilecek esnekliğe sahipse, Token Bucket en doğru seçenektir. SaaS ürünlerinin standart API uç noktaları, kullanıcıların sayfa geçişlerinde yoğun veri çektiği mobil uygulamalar ve entegrasyon servisleri genellikle bu algoritmayı kullanır. AWS WAF ve birçok modern API Gateway (örneğin Kong veya Apigee) varsayılan olarak Token Bucket veya onun bir varyasyonu olan Leaky Bucket algoritmasını sunar.

Öte yandan, katı sınırların korunması gereken ve aşırı yüklenmenin doğrudan finansal veya operasyonel zarara yol açacağı durumlarda Sliding Window tercih edilmelidir. Özellikle ödeme geçitleri (payment gateways), biletleme sistemleri, kupon kodu kullanım uç noktaları ve üçüncü taraf API'lere (örneğin pahalı yapay zeka/LLM çağrıları yapan uç noktalar) yapılan isteklerin sınırlandırılmasında Sliding Window vazgeçilmezdir. Finansal dolandırıcılık girişimlerini engellemek için tasarlanan limitler, zaman pencerelerinin kesişim yerlerindeki sızıntılardan faydalanılmaması için Sliding Window'un keskin sınır korumasına ihtiyaç duyar.

Maliyet odaklı yaklaşımlarda ise altyapı bütçesi belirleyici rol oynar. Milyonlarca aktif kullanıcısı olan bir platformda Sliding Window Log kullanmak, Redis sunucularınızın bellek kapasitesini (RAM) hızla tüketerek barındırma maliyetlerini katlayabilir. Bu durumda, bellek tüketimini $O(1)$ seviyesinde tutan Token Bucket veya yaklaşık hesaplama yapan Sliding Window Counter modelleri devreye sokulmalıdır. Altyapı maliyetini optimize ederken API güvenliğini üst seviyede tutmak, ancak her bir uç noktanın kritiklik derecesine göre hibrit bir mimari kurmakla mümkündür.