API Rate Limiting ve Throttling Stratejileri Rehberi [2026]

API Rate Limiting Nedir ve Neden Gereklidir?

Modern yazilim mimarilerinde API'ler, sistemlerin birbiriyle iletisim kurdugu temel noktalardir. Ancak sinirlandirilmamis erisim, hem performans sorunlarina hem de guvenlik aciklarina yol acar. Rate limiting, belirli bir zaman diliminde bir istemcinin yapabilecegi istek sayisini sinirlandirarak API altyapisini koruyan temel bir mekanizmadir.

Rate limiting olmadan bir API, asiri yukleme saldirilarina (DDoS), kaynak tuketimi istismarina ve haksiz kullanim senaryolarina acik hale gelir. Ayrica coklu kiracili (multi-tenant) sistemlerde, tek bir istemcinin tum kaynaklari tuketmesini onlemek icin adil kullanim politikalari zorunludur. Ozellikle mikro servis mimarilerinde, bir servisin asiri yuklenmenin diger servislere yayilmasini engellemek icin rate limiting cascade failure'larin onune gecen kritik bir mekanizmadir.

Throttling ise rate limiting'in bir alt kategorisi olarak, isteklerin tamamen reddedilmesi yerine yavaslatilmasini ifade eder. Bu yaklasim, istemciye daha yumusak bir deneyim sunarken sunucu kaynaklarini korur. Kuyruk tabanli throttling, istekleri bir siraya alarak kapasite musait oldugunda isler; bu sayede hicbir istek kaybolmaz, yalnizca geciktirilir.

Rate Limiting Algoritmalari

Rate limiting uygulamalarinda farkli algoritmalar, farkli kullanim senaryolarina uygun cozumler sunar. Dogru algoritma secimi, sistemin gereksinimlerine ve trafik desenlerine baglidir. Asagida en yaygin bes algoritmayi detaylariyla inceliyoruz.

Token Bucket Algoritmasi

Token bucket, en yaygin kullanilan rate limiting algoritmalarindan biridir. Bir kovaya belirli bir hizda token eklenir ve her istek bir token tuketir. Kova bos oldugunda istekler reddedilir. Algoritmanin iki temel parametresi vardir: kova kapasitesi (maximum burst size) ve token yenileme hizi (refill rate).

Bu algoritmanin temel avantaji, burst trafige izin vermesidir. Kova doluyken istemci kisa sureli yuksek trafik patlamalari gerceklestirebilir. Amazon API Gateway ve Stripe gibi buyuk olcekli platformlar token bucket algoritmasini tercih eder. Ornegin dakikada 100 istek limiti olan bir API'de kova kapasitesi 100 ve yenileme hizi saniyede yaklasik 1.67 token olarak ayarlanabilir.

Farkli API endpoint'lerine farkli maliyet degerleri atanarak, agir islemlerin daha fazla token tuketmesi saglanabilir. Bir GET istegi 1 token tuketirken, karmasik bir rapor olusturma istegi 10 token tuketebilir. Bu agirlikli yaklasim, kaynak tuketimini daha adil bir sekilde yansitir.

Leaky Bucket Algoritmasi

Leaky bucket, token bucket'in tersi mantikla calisir. Istekler bir kuyruga eklenir ve sabit bir hizda islenir. Kuyruk dolgdugunda yeni istekler reddedilir. Bu algoritma, trafik sekillendirme (traffic shaping) icin idealdir cunku cikis hizi her zaman sabittir ve bu da arka uc sistemlerin onceden tahmin edilebilir bir yuk altinda calismasini garantiler.

Leaky bucket'in en buyuk avantaji, arka uc sistemlere duzenli ve onceden tahmin edilebilir bir trafik akisi saglamasidir. Veritabani baglantisi gibi sinirli kaynaklara erisim gerektiren endpoint'lerde, sabit cikis hizi kaynak tuketimini kontrol altinda tutar. Ancak burst trafige izin vermemesi, gecikmeye duyarli uygulamalarda dezavantaj olusturabilir.

Fixed Window Algoritmasi

Fixed window, en basit rate limiting algoritmasidir. Zaman sabit pencerelere bolunur (ornegin dakikalik) ve her pencerede belirli sayida istege izin verilir. Pencere sona erdiginde sayac sifirlanir. Uygulamasi basit ve bellek tuketimi minimalddir; yalnizca bir sayac ve pencere baslangic zamani saklanir.

Bu yaklasimdaki temel sorun, pencere sinirlarinda ortaya cikan "boundary burst" problemidir. Bir istemci bir pencerenin son saniyesinde 100 istek ve bir sonraki pencerenin ilk saniyesinde 100 istek gonderirse, 2 saniye icinde 200 istek yapabilir. Bu davranis, dakikada 100 istek limitinin ruhuna aykiri olsa da teknik olarak kurallari ihlal etmez.

Sliding Window Log Algoritmasi

Sliding window log, her istegin zaman damgasini kaydederek calisir. Yeni bir istek geldiginde, son N saniye icindeki tum istekler sayilir ve limite gore karar verilir. Bu algoritma fixed window'un boundary burst sorununu tamamen cozer ve en hassas rate limiting'i saglar.

Ancak her istegin zaman damgasini saklamak bellek tuketimini onemli olcude arttirir. Dakikada 1000 istek limiti olan bir istemci icin, 1000 zaman damgasinin bellekte tutulmasi gerekir. Yuksek trafikli sistemlerde bu maliyet kabul edilemez boyutlara ulasabilir. Bu nedenle genellikle dusuk hacimli ancak yuksek hassasiyet gerektiren premium API planlari gibi senaryolarda tercih edilir.

Sliding Window Counter Algoritmasi

Sliding window counter, fixed window ve sliding window log arasinda bir denge kurar. Onceki ve mevcut penceredeki istek sayilarina agirlikli ortalama uygulayarak yaklasik bir sliding window hesaplamasi yapar. Ornegin mevcut pencere yuzde 30 ilerlenmisse, onceki pencerenin istek sayisinin yuzde 70'i ile mevcut pencerenin istek sayisi toplanir.

Bu algoritma, yalnizca iki sayac (onceki ve mevcut pencere) ile minimal bellek kullaniminda fixed window'un boundary burst sorununu buyuk olcude ortadan kaldirir. Cloudflare, Redis ve bircok buyuk olcekli platform bu yaklasimi benimser. Hassasiyet ve performans arasindaki dengesi, cogu uretim ortami icin ideal secimdir.

Dagitik Rate Limiting Mimarisi

Tekil sunucu ortamlarinda rate limiting nispeten basittir; bellek ici bir sayac yeterlidir. Ancak mikroservis mimarilerinde ve coklu sunucu yapilarinda, tum instance'lar arasinda tutarli sinirlandirma saglamak icin dagitik rate limiting kritik bir gereksinime donusur.

Redis Tabanli Dagitik Rate Limiting

Redis, dagitik rate limiting icin en yaygin kullanilan veri deposudur. Atomik islemleri, dusuk gecikme suresi (sub-millisecond) ve TTL (Time-To-Live) destegi ile rate limiting sayaclarini yonetmek icin idealdir. Redis Cluster kullanildiginda, yatay olceklenebilirlik de elde edilir.

Lua script'leri, Redis uzerinde atomik rate limiting mantigi calistirmak icin guclu bir aractir. Tek bir atomik islemde sayac kontrolu, artirimi ve karar verme islemi gerceklestirilebilir, bu da yarisma kosullarini (race condition) tamamen ortadan kaldirir. EVALSHA komutu ile onceden yuklenmis script'ler, her istekte script'i yeniden gondermekten kaynaklanan ag yukunu azaltir.

Redis'in high availability yapisi icin Redis Sentinel veya Redis Cluster kullanilmalidir. Redis'in gecici olarak erisilemez olmasi durumunda, rate limiting'in basarisiz acik mi (fail open — tum isteklere izin ver) yoksa basarisiz kapali mi (fail closed — tum istekleri reddet) calisacagi tasarim asamasinda belirlenmeli ve dokumante edilmelidir.

API Gateway Katmaninda Rate Limiting

API gateway'ler, rate limiting'in merkezi olarak uygulanmasi icin dogal bir noktadir. Kong, Tyk, AWS API Gateway, Azure API Management ve Envoy gibi platformlar yerlesik rate limiting ozellikleri sunar. Bu cozumler genellikle yapılandırma tabanli calisir ve kod degisikligi gerektirmez.

Gateway katmaninda rate limiting uygulamanin avantaji, tum arka uc servislerin tek bir noktadan korunmasidir. Ayrica rate limiting politikalarinin servis kodundan bagimsiz olarak yonetilmesi, operasyonel esneklik saglar. Dezavantaji ise gateway'in tek hata noktasi (single point of failure) olma riskidir; bu nedenle gateway'in kendisinin yuksek erisilebilirlik icin yapilandirilmasi gerekir.

Middleware Tabanli Yaklasim

Uygulama katmaninda middleware olarak rate limiting uygulamak, daha ince granularite kontrolu saglar. Her endpoint icin farkli limitler, kullanici rolune gore dinamik sinirlar ve islem tipine gore agirlikli limitler tanimlanabilir. Bu esneklik, ozellikle karmasik is mantigi iceren API'lerde degerlidir.

Express.js icin express-rate-limit, Django icin django-ratelimit, Spring Boot icin Bucket4j ve ASP.NET icin AspNetCoreRateLimit gibi kutuphaneler, middleware tabanli rate limiting icin hazir cozumler sunar. Bu kutuphaneler genellikle bellek ici (in-memory) ve Redis tabanli depolama seceneklerini destekler.

Rate Limit Header'lari ve Istemci Tarafli Yonetim

API'lerin rate limit durumunu istemcilere iletmesi, saglikli bir ekosistem icin zorunludur. IETF taslak standardi (RateLimit header fields for HTTP — RFC 6585 ve draft-ietf-httpapi-ratelimit-headers), bu iletisim icin bir cerceve tanimlar.

Standart Rate Limit Header'lari

RateLimit-Limit header'i toplam izin verilen istek sayisini, RateLimit-Remaining kalan istek sayisini ve RateLimit-Reset limitin sifirlanacagi zamani bildirir. HTTP 429 Too Many Requests durum kodu, rate limit asimini isaret eder. Retry-After header'i ise istemcinin ne kadar sure beklemesi gerektigini saniye cinsinden veya belirli bir tarih olarak iletir.

Bu header'larin tutarli ve dogru sekilde uygulanmasi, istemci gelistiricilerin rate limit'lere uygun davranmasini kolaylastirir. Ozellikle SDK ve kutuphane gelistiricileri icin bu bilgiler kritik oneme sahiptir. Yanit govdesinde de detayli hata mesaji, limit turu ve yukseltme secenekleri sunulmasi, gelistirici deneyimini iyilestirir.

Istemci Tarafli Rate Limit Yonetimi

Iyi tasarlanmis API istemcileri, rate limit header'larini okuyarak isteklerini otomatik olarak ayarlamalidir. Exponential backoff stratejisi, 429 yaniti alindiktan sonra artan bekleme sureleriyle yeniden deneme yapar: ilk denemede 1 saniye, ikinci denemede 2 saniye, ucuncude 4 saniye gibi katlanarak artan bekleme sureleri uygulanir.

Jitter (rastgele gecikme) eklemek, birden fazla istemcinin ayni anda yeniden denemesini (thundering herd problemi) onler. Istemci tarafinda yerel kuyruk ve hiz kontrolu mekanizmalari, gereksiz 429 yanitlarini minimize eder. Istemci SDK'larinda proaktif rate limiting — kalan kota izlenerek sunucu yaniti beklemeden isteklerin yavaslatilmasi — en olgun yaklasimdir.

Adaptif Rate Limiting

Sabit limitler her zaman optimal degildir. Trafik desenleri gun icinde degisir, beklenmedik yuk artislari olabilir ve farkli istemciler farkli kaynak tuketim profillerine sahiptir. Adaptif rate limiting, bu degiskenliklere dinamik olarak uyum saglar.

Sistem Yukune Dayali Adaptasyon

CPU kullanimi, bellek durumu, ortalama yanit suresi, hata orani ve aktif baglanti sayisi gibi metrikler izlenerek, sistem yuku arttikca rate limit'ler otomatik olarak dusurulur. Ornegin CPU kullanimi yuzde 80'i astiginda, rate limit'ler yuzde 50 azaltilabilir. Bu yaklasim, sunucu kaynaklarinin asiri yuklenmesini proaktif olarak onler ve sistemin karararli calismasini saglar.

Circuit breaker deseni ile entegre adaptif rate limiting, arka uc servislerin saglik durumuna gore on uc API'nin kabul ettigi trafigi ayarlar. Arka uc servis yavasladiginda veya hata verdiginde, rate limit otomatik olarak daraltilir.

Istemci Davranisina Dayali Adaptasyon

Istemcilerin gecmis davranislari analiz edilerek, guvenilir istemcilere daha yuksek limitler, supheli davranislar gosteren istemcilere ise daha dusuk limitler atanabilir. Bu yaklasim, API ekosisteminde adil kullanimi tesvik eder ve iyi niyetli istemcileri odullendirir.

Makine ogrenimi tabanli istemci skorlama, istek desenleri, hata oranlari ve kullanim gecmisini analiz ederek dinamik limit atamalari yapabilir. Anormal davranis tespitinde (ani trafik artisi, olagan disi endpoint erisim deseni) geçici olarak daha kati limitler uygulanir.

API Kota Yonetimi

Rate limiting anlik trafik kontrolune odaklanirken, kota yonetimi daha uzun vadeli kullanim sinirlarini kapsar. Gunluk, haftalik veya aylik API cagrisi limitleri, genellikle ticari API planlarinin temelini olusturur ve gelir modelinin teknik altyapisini saglar.

Katmanli Kota Modelleri

Ucretsiz, baslangic, profesyonel ve kurumsal gibi farkli planlarda farkli kota seviyeleri tanimlanir. Her plan, farkli rate limit'ler, farkli endpoint erisimleri ve farkli kota miktarlari icerebilir. Ornegin ucretsiz planda gunluk 1000 istek ve dakikada 10 istek limiti uygulanirken, kurumsal planda aylik 10 milyon istek ve dakikada 1000 istek limitine izin verilebilir.

Kota asimi durumunda, istemcinin otomatik olarak bir ust plana yukseltilmesi (auto-scaling) veya fazla kulllanimin faturalanmasi (overage billing) gibi stratejiler uygulanabilir. Sert kesme (hard cap) yaklasimi ise kota asiminda tum istekleri reddeder.

Kota Izleme ve Raporlama

Istemcilere kota kullanimlarini goruntuuleme imkani sunmak, surpriz asim durumlarini onler. Dashboard'lar, bildirimler (kota yuzde 80'e ulastiginda uyari) ve API uzerinden kota sorgulama endpoint'leri, iyi bir kota yonetim sisteminin bilesenleridir. Detayli kullanim raporlari, istemcilerin API kullanim desenlerini anlamalarini ve optimize etmelerini saglar.

DDoS Korumasi ve Rate Limiting

Rate limiting, DDoS saldirilarina karsi ilk savunma hattini olusturur. Ancak tek basina yeterli degildir ve kapsamli bir guvenlik stratejisinin parcasi olarak degerlendirilmelidir. Katmanli bir savunma yaklasimi en etkili stratejidir.

Katmanli Savunma Stratejisi

CDN katmaninda (Cloudflare, Akamai, Fastly) global trafik filtreleme ve DDoS korumasi, API gateway katmaninda kimlik dogrulamasi ve rate limiting, uygulama katmaninda is mantigi temelli sinirlandirma ve altyapi katmaninda ag seviyesi koruma (WAF, IDS/IPS) bir arada uygulanmalidir. Her katman, farkli saldiri vektorlerine karsi koruma saglar.

Aggregator ve Bot Trafigi Yonetimi

Veri toplama amacli botlar ve aggregator servisler, API trafiginin onemli bir bolumunu olusturabilir. Bu trafigi yonetmek icin ozel rate limit politikalari tanimlamak, hem API sagligi hem de is ortakliklari acisindan onemlidir. Dogrulanmis aggregator partnerlere ozel API anahtarlari ve daha yuksek limitler sunmak, kontrolsuz scraping yerine yapilandirilmis veri erisimi saglar.

Smart Maple olarak, API rate limiting stratejilerinin hem teknik guvenlik hem de is surekliligi acisindan kritik oldugunu deneyimlerimizle biliyoruz. Partner API programlari, is birligine dayali veri paylasimini tesvik ederken API altyapisini korur.

Rate Limiting Uygulama En Iyi Pratikleri

Basarili bir rate limiting stratejisi icin bazi temel prensiplere uymak gerekir. Bu prensipler, hem teknik saglamlik hem de gelistirici deneyimi acisindan onem tasir.

Granularite Secimi

Rate limiting, IP adresi, API anahtari, kullanici kimligi veya bunlarin kombinasyonuna gore uygulanabilir. IP tabanli sinirlandirma, NAT arkasindaki kullanicilari olumsuz etkileyebilir cunku ayni IP'yi paylasan yuzlerce kullanici tek bir istemci gibi degerlendirilir. API anahtari tabanli sinirlandirma, daha hassas kontrol saglar ancak kimlik dogrulamasi gerektirir. Hibrit yaklasimlar, kimlik dogrulamasi yapilmamis isteklere IP tabanli, dogrulanmis isteklere anahtar tabanli sinirlandirma uygular.

Loglama ve Izleme

Rate limit olaylari mutlaka loglanmali ve izlenmelidir. Hangi istemcilerin sureklii limite takildigi, hangi endpoint'lerin en fazla sinirlandirildigi, rate limit'lerin is etkisi ve false positive durumlarinin (meşru isteklerin yanlis sinirlandirililmasi) sikligi analiz edilmelidir. Prometheus ve Grafana gibi araclarla rate limiting metriklerinin gorsellestirilmesi, operasyonel karar vermeyi destekler.

Graceful Degradation

Rate limit asiminda istemciye yalnizca 429 yaniti dondurmek yerine, anlamli hata mesajlari, kalan bekleme suresi, limit turleri ve alternatif eylem onerileri sunulmalidir. Yanit govdesinde JSON formatinda limit detaylari, asim nedeni ve dokumantasyon linki saglamak, gelistirici deneyimini onemli olcude iyilestirir ve destek taleplerini azaltir.

Test ve Dogrulama

Rate limiting mekanizmalarinin yuk testleri ile dogrulanmasi, uretim ortaminda beklenmedik davranislarin onune gecer. Farkli trafik desenleri, boundary kosullari, dagitik senaryolar ve Redis erisim kesintisi gibi hata durumlari test edilmelidir. Chaos engineering pratikleri, rate limiting altyapisinin dayanikliligini dogrulamak icin degerli bir yaklasimdir.

Sonuc

API rate limiting ve throttling, modern API altyapisinin vazgecilmez bilesenleridir. Dogru algoritma secimi, dagitik ortamlarda tutarli uygulama, istemci dostu header'lar ve adaptif stratejiler, saglam bir rate limiting mimarisinin temel taslarini olusturur. Hem API saglayicilari hem de tuketicileri icin, rate limiting mekanizmalarini anlamak ve dogru uygulamak, guvenilir ve olceklenebilir sistemler insa etmenin on kosullarindandir. Kota yonetimi ve DDoS korumasi ile birlesikte, rate limiting kapsamli bir API guvenlik stratejisinin temelini atar.