API Hız Sınırlama (Rate Limiting): Neden Gerekli ve Nasıl Yapılır?

Bir API'yi dünyaya açtığınızda, ona kimin ne kadar sık erişeceğini kontrol edemezsiniz. İyi niyetli bir istemci hatalı bir döngü yüzünden saniyede yüzlerce istek gönderebilir; kötü niyetli biri ise sisteminizi kasıtlı olarak boğmaya çalışabilir. Her iki durumda da sonuç aynıdır: sunucu yorulur, gerçek kullanıcılar yavaşlar ve sistem çökebilir. İşte hız sınırlama (rate limiting), tam da bu tehlikeye karşı API'nin trafik polisi görevini görür.

Hız Sınırlama Neden Gereklidir?

Hız sınırlama, yalnızca teknik bir önlem değil; adalet, güvenlik ve istikrar meselesidir. Sınırsız erişime izin veren bir API, birkaç sorunla karşı karşıyadır:

• Kaynak korunması: Sunucu kapasitesi sonsuz değildir; aşırı istek tüm kullanıcıları etkiler.
• Adil paylaşım: Bir istemcinin aşırı kullanımı, diğerlerinin hizmetini bozmamalıdır.
• Kötüye kullanım önleme: Kaba kuvvet saldırıları ve veri kazıma (scraping) girişimleri sınırlarla yavaşlatılır.
• Maliyet kontrolü: Her istek işlem gücü ve para demektir; sınır, maliyetleri öngörülebilir tutar.

Hız sınırlama olmayan bir API, kapısında bekçi olmayan bir bina gibidir. İçeri girmek isteyen herkes, meşru ziyaretçilerin geçişini engelleyecek kadar kalabalıklaşabilir.

Başlıca Hız Sınırlama Algoritmaları

Hız sınırlamayı uygulamanın birkaç klasik yöntemi vardır. Her birinin kendine göre denge noktaları bulunur.

Sabit Pencere (Fixed Window)

En basit yöntemdir. Belirli bir zaman aralığında (örneğin dakikada) izin verilen istek sayısı sayılır. "Dakikada en fazla 100 istek" kuralı bu mantıkla çalışır. Sadedir ancak pencere sınırında ani yığılmalara açıktır; bir dakikanın sonunda ve bir sonrakinin başında yapılan istekler kısa sürede iki katına çıkabilir.

Kayan Pencere (Sliding Window)

Sabit pencerenin sınır sorununu, zamanı sürekli kayan bir aralık olarak değerlendirerek çözer. Daha adil bir dağılım sağlar ancak biraz daha karmaşıktır ve daha fazla bellek gerektirir.

Token Kovası (Token Bucket)

En esnek ve yaygın yöntemlerden biridir. Her istemci için bir "kova" düşünün; kovaya belirli hızda token eklenir ve her istek bir token harcar. Kova boşsa istek reddedilir. Bu yöntemin güzelliği, kısa süreli yoğunluklara (burst) izin verirken uzun vadeli ortalamayı sınırlamasıdır.

// Basitlestirilmis token bucket mantigi
if ($bucket['tokens'] >= 1) {
    $bucket['tokens'] -= 1;
    // istegi isle
} else {
    http_response_code(429);
    header('Retry-After: 60');
    echo json_encode(['hata' => 'Cok fazla istek']);
}

429 Yanıtı ve İstemcinin Sorumluluğu

Bir istemci sınırı aştığında, sunucu genellikle 429 Too Many Requests durum kodunu döner. İyi tasarlanmış bir API, bu yanıtla birlikte istemciye ne zaman tekrar deneyebileceğini de söyler:

• Retry-After başlığı: Kaç saniye sonra tekrar denenebileceğini belirtir.
• X-RateLimit-Limit: İzin verilen toplam istek sayısı.
• X-RateLimit-Remaining: Kalan istek hakkı.
• X-RateLimit-Reset: Sınırın ne zaman sıfırlanacağı.

İstemci tarafında sorumluluk ise bu bilgilere saygı göstermektir. 429 yanıtı alan iyi bir istemci hemen tekrar denemek yerine, Retry-After süresini bekler. Ayrıca üst üste hata alındığında bekleme süresini kademeli olarak artırmak (exponential backoff), hem sunucuyu rahatlatır hem de istemcinin bir an önce hizmet almasına yardımcı olur.

Sınıra çarpan istemci için doğru davranış, kapıyı daha hızlı çalmak değil, sabırla beklemektir. Panikle atılan tekrar istekleri, sadece durumu kötüleştirir.

Sınırları Nasıl Belirlemeli?

Doğru sınır, projeye göre değişir ve genellikle deneyimle ayarlanır. Çok gevşek sınırlar koruma sağlamaz; çok katı sınırlar meşru kullanıcıları rahatsız eder. Pratik bir yaklaşım, farklı istemci sınıflarına farklı sınırlar tanımlamaktır:

1. Anonim (kimliksiz) isteklere düşük sınır.
2. Kimlik doğrulamış kullanıcılara daha yüksek sınır.
3. Kurumsal veya ücretli iş ortaklarına özel, geniş sınırlar.

Sınırları kullanıcı, IP adresi ya da API anahtarı bazında uygulayabilirsiniz. Genellikle en adil olanı, kimliği doğrulanmış istemciyi anahtarı üzerinden sınırlamaktır; çünkü tek bir IP'nin arkasında birçok meşru kullanıcı olabilir.

Berasoft Yaklaşımı

Geliştirdiğimiz API'lerde hız sınırlamayı en baştan mimarinin bir parçası olarak ele alırız; çünkü sonradan eklenen bir sınır, çoğu zaman sistem zaten bir kez çöktükten sonra düşünülür. Doğru algoritma seçimi, anlamlı sınırlar ve açık 429 yanıtlarıyla kurulan bir sistem, hem sunucuyu korur hem de meşru kullanıcıları memnun eder. Kurumsal API'nizi güvenli ve ölçeklenebilir kılmak isterseniz bizimle iletişime geçebilirsiniz.

Sonuç

Hız sınırlama, bir API'nin sağlığını ve adaletini koruyan temel bir mekanizmadır. Kaynakları tükenmekten korur, kötüye kullanımı engeller ve tüm kullanıcılara adil bir hizmet sunar. Token kovası gibi esnek algoritmalar, kısa yoğunluklara izin verirken genel dengeyi korur. En önemlisi, sunucu tarafında açık 429 yanıtları vermek ve istemci tarafında bu yanıtlara saygıyla, kademeli beklemeyle karşılık vermek, sağlıklı bir ekosistemin iki yakasıdır. İyi kurulmuş bir sınır, kimsenin fark etmediği ama herkesin faydalandığı sessiz bir korumadır.