API Rate Limit Nedir, Neden Gerekir?

Bir sabah sitenizin yavaşladığını, mobil uygulamanın açılmadığını fark ediyorsunuz. Kayıtlara baktığınızda tek bir IP adresinin dakikada binlerce kez ürün listesini çektiğini görüyorsunuz; belki bir rakibin fiyat toplama botu, belki de bir iş ortağının hatalı yazılmış entegrasyonu. Bu tür durumlara karşı ilk savunma hattı istek sınırlamadır. API rate limit, bir istemcinin belirli bir zaman aralığında API’ye gönderebileceği istek sayısına konulan üst sınırdır. Bu yazıda neden gerektiğini, nasıl çalıştığını ve hem API sahibi hem de API kullanan taraf olarak nelere dikkat etmeniz gerektiğini anlatacağım.

API rate limit neden gerekir?

İstek sınırlamayı yalnızca saldırılara karşı bir önlem olarak görmek eksik olur. Gündelik işleyişte de birçok sorunu önler:

• Sunucuyu korumak: Ani ve aşırı istekler, sunucunun herkese hizmet veremez hâle gelmesine yol açabilir.
• Adil kullanım: Tek bir istemcinin kaynakları tüketip diğer kullanıcıları yavaşlatması engellenir.
• Kaba kuvvet saldırılarını yavaşlatmak: Giriş veya şifre sıfırlama ekranında binlerce şifre denemesi pratik olmaktan çıkar.
• Veri kazımayı zorlaştırmak: Tüm ürün ve fiyat listenizin dakikalar içinde kopyalanması zorlaşır.
• Hatalı kodun etkisini sınırlamak: Sonsuz döngüye giren bir entegrasyon, tüm sistemi kilitlemeden durdurulur.
• Maliyet kontrolü: Ücretli üçüncü taraf servislere veya yapay zekâ modellerine bağlanan uç noktalarda faturanın kontrolsüz büyümesi önlenir.

İstek sınırlama, API’yi korumanın katmanlarından yalnızca biridir; kimlik doğrulama ve yetkilendirmeyle birlikte düşünülmelidir. Bu bütünü API güvenliği: kimlik doğrulama, yetki ve sınırlama yazısında anlattım.

Sınır neye göre konur?

Bir API rate limit kuralı üç sorunun cevabından oluşur: kime, ne kadar ve hangi süre için? “Kime” sorusunun yaygın cevapları şunlardır:

• IP adresi: Giriş yapılmamış istekler için pratiktir; ancak aynı ağı paylaşan çok sayıda kullanıcı (ör. bir şirket ağı) tek IP’den çıkabilir.
• Kullanıcı veya API anahtarı: Kimliği doğrulanmış istemciler için daha adildir.
• Uç nokta: Giriş, şifre sıfırlama, SMS gönderme gibi hassas veya maliyetli işlemler için ayrı ve daha sıkı sınırlar konur.

Farklı müşteri gruplarına farklı sınırlar da tanımlanabilir. Örneğin bayilere açılan bir API’de büyük bayiler için daha yüksek bir kota belirlemek mümkündür.

Yaygın sınırlama algoritmaları

Algoritma	Nasıl çalışır?	Artısı / eksisi
Sabit pencere	Her dakika gibi sabit aralıklarda sayaç sıfırlanır	Basit; ancak pencere sınırında kısa süreli yığılmaya izin verir
Kayan pencere	Son belirli süredeki istekler sürekli hesaplanır	Daha adil; biraz daha fazla hesaplama gerektirir
Jeton kovası (token bucket)	Kovaya düzenli jeton eklenir, her istek bir jeton harcar	Kısa ani artışlara izin verirken ortalamayı sınırlar
Sızdıran kova (leaky bucket)	İstekler sabit hızda işlenir, fazlası bekletilir veya reddedilir	Sunucuya düzgün bir yük akışı sağlar

Çoğu işletme projesinde jeton kovası veya kayan pencere yeterli ve dengeli sonuç verir. Birden fazla sunucuda çalışan sistemlerde sayaçların Redis gibi ortak bir bellekte tutulması gerekir; aksi hâlde her sunucu kendi sayacını tutar ve sınır fiilen katlanır.

Nerede uygulanır?

İstek sınırlama birkaç katmanda uygulanabilir ve genellikle birlikte kullanılır. Uygulama kodunda kullanıcıya ve uç noktaya özel kurallar yazılır. Sunucu önündeki Nginx gibi bir ters vekil (reverse proxy) katmanında ise kaba ama çok hızlı bir ilk filtre kurulabilir:

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /api/ {
    limit_req zone=api burst=20 nodelay;
}

Bu örnek, her IP için saniyede ortalama 10 isteğe izin verir ve kısa süreli 20 isteklik bir taşmayı tolere eder. Değerler örnektir; gerçek trafiğe göre belirlenmelidir. CDN ve güvenlik duvarı hizmetleri de benzer kurallar sunar. Ayrıca sık istenen ve seyrek değişen veriler önbellekten sunulursa sınıra takılan istek sayısı da kendiliğinden azalır; bu konuyu API önbellekleme yazısında ele aldım.

Sınır aşıldığında ne olur? 429 hatası

Sınırı aşan isteğe standart cevap, HTTP 429 Too Many Requests durum kodudur. İyi tasarlanmış bir API, bu cevapla birlikte Retry-After başlığında ne kadar sonra tekrar denenebileceğini bildirir. Pek çok API ayrıca kalan istek hakkını ve sayacın ne zaman sıfırlanacağını cevap başlıklarında paylaşır; böylece istemci sınıra gelmeden yavaşlayabilir.

API kullanan taraf olarak ne yapmalısınız?

Bir kargo, ödeme ya da pazaryeri API’sine bağlanıyorsanız onların sınırlarına takılmamak da sizin sorumluluğunuzdur:

1. Sağlayıcının güncel limitlerini dokümantasyonundan öğrenin; limitler zamanla değişebilir.
2. 429 aldığınızda hemen tekrar denemeyin; Retry-After süresine uyun ya da bekleme süresini her denemede artırın (exponential backoff).
3. Toplu işlemleri zamana yayın; binlerce ürünü aynı saniyede güncellemek yerine kuyruğa alın.
4. Değişmeyen veriyi tekrar tekrar sormak yerine önbelleğe alın; mümkünse webhook ile bildirim almayı tercih edin.

Bu işi nasıl birlikte yaparız?

API’nize istek sınırlama eklemek ya da bağlandığınız servislerin limitlerine takılan bir entegrasyonu düzeltmek için şu adımları izliyorum:

1. Trafiği anlama: Mevcut kayıtlardan hangi uç noktaların, kimler tarafından, ne yoğunlukta kullanıldığını birlikte inceleriz.
2. Kural tasarımı ve teklif: Kullanıcı, IP ve uç nokta bazında sınırları; hassas işlemler için ayrı kuralları içeren bir öneri ve teklif hazırlarım.
3. Uygulama ve test: Sınırları uygulama ve sunucu katmanında kurar, yük testleriyle hem gerçek kullanıcıların etkilenmediğini hem de aşırı isteklerin durdurulduğunu doğrularım.
4. Teslim ve izleme: 429 cevaplarını ve şüpheli trafiği izleyen bir kayıt düzeni kurar, gerektiğinde sınırları birlikte güncelleriz.

İhtiyacınızı anlatmak için iletişim sayfasından bana ulaşabilirsiniz.

Sık sorulan sorular

Rate limit gerçek kullanıcılarımı engeller mi?

Sınırlar gerçek kullanım verisine göre belirlenirse normal kullanıcılar fark etmez. Ani artışlara izin veren algoritmalar ve kimlik bazlı kurallar, yanlışlıkla engellenme riskini azaltır.

Rate limit DDoS saldırılarını tamamen durdurur mu?

Hayır. Uygulama düzeyindeki sınırlama, büyük ölçekli dağıtık saldırılara karşı tek başına yeterli değildir. Bu tür saldırılar için ağ ve CDN düzeyinde koruma gerekir.

Kota ile rate limit aynı şey mi?

Yakın kavramlardır. Rate limit genellikle kısa süreli hızı (saniye, dakika), kota ise daha uzun dönemdeki toplam kullanımı (gün, ay) sınırlar.

Üçüncü taraf bir API’nin limitine takılırsam ne olur?

İstekleriniz geçici olarak reddedilir. Tekrar deneme kurallarına uymazsanız bazı sağlayıcılar erişimi daha uzun süre kısıtlayabilir; güncel kuralları sağlayıcının dokümantasyonundan kontrol edin.

Sonuç

API rate limit, sunucunuzu aşırı yükten, kullanıcılarınızı haksız kaynak tüketiminden ve sisteminizi kaba kuvvet denemelerinden koruyan basit ama etkili bir önlemdir. Doğru kurgulandığında gerçek kullanıcılar fark etmez, kötüye kullanım ise erkenden durdurulur. API’niz için uygun sınırları birlikte belirlemek isterseniz bana yazabilirsiniz.