Rate Limiting Nedir? API’yi 30 Dakikada Koru

Meta Description

Rate limiting ile API’nizi abuse ve trafik patlamalarına karşı koruyun. Token bucket, sliding window, Nginx ve Node.js örnekleriyle başlayın.

Giriş (Introduction)

Bir sabah uyanıp API maliyetlerinizin fırladığını, sunucunun CPU’sunun %100’e dayandığını ve “normal” görünen trafik yüzünden sistemin yanıt veremez hale geldiğini düşünün. Sebep çoğu zaman karmaşık değildir: kontrolsüz istek trafiği (botlar, yanlış yazılmış entegrasyonlar, agresif mobil istemciler, hatta basit bir döngü hatası).

İşte burada rate limiting devreye girer. Rate limiting, bir kullanıcıya/anahtara/IP’ye belirli bir zaman aralığında yapılabilecek istek sayısını sınırlar. Bu yazıyı okuduğunuzda rate limiting’in mantığını, hangi tür limitin hangi senaryoda işe yaradığını ve Nginx ile hızlı kurulum ile Node.js (Express) üzerinde örnek uygulamayı adım adım öğreneceksiniz.

---

Rate Limiting Nedir? (Ana Kavram)

Rate limiting, bir kaynağa (API endpoint’i gibi) gelen isteklerin hızını kontrol etmektir. Amaç:

• Kötüye kullanımı (abuse) azaltmak
• DDoS etkisini sınırlamak (tam çözüm değil ama önemli bir katman)
• Adil kullanım sağlamak (free vs pro plan)
• Maliyetleri kontrol etmek (özellikle 3rd-party API çağrıları pahalıysa)
• Sistemi stabil tutmak (ani trafik patlamalarında)

Rate limiting genelde şu kimliklerden biriyle uygulanır:

• IP adresi
• Kullanıcı ID (JWT içinden)
• API key
• Tenant / organization ID

Bunu neden yapmalıyım? Çünkü tek bir hatalı istemci bile “sonsuz retry” ile sisteminizi çökertir; rate limiting ise hasarı kontrollü seviyede tutar.

---

Rate Limiting Türleri: Hangisini Ne Zaman Kullanmalı?

Rate limiting algoritması seçimi uygulamanın trafiğine göre değişir. En yaygın türler:

1) Fixed Window (Sabit Pencere)

Belirli bir zaman diliminde (örn. 1 dakikada 60 istek) sayaç tutar.

• Artı: Uygulaması kolay
• Eksi: Pencere sınırında “burst” (patlama) oluşturabilir (59. saniyede 60 istek + 1. saniyede 60 istek)

2) Sliding Window (Kayan Pencere)

Son N saniyedeki istekleri daha “akıcı” ölçer.

• Artı: Daha adil ve stabil
• Eksi: Uygulaması daha karmaşık

3) Token Bucket (Jeton Kovası)

Belirli hızda token üretilir; her istek 1 token harcar. Token birikimi kısa süreli patlamalara izin verir.

• Artı: Burst trafikte iyi
• Eksi: Konfigürasyon doğru yapılmazsa beklenmedik davranışlar

4) Leaky Bucket (Sızıntılı Kova)

İstekleri sabit hızda “sızdırır”; kuyruk dolarsa reddeder.

• Artı: Çıkış hızını düzleştirir
• Eksi: Gecikme oluşturabilir

Hızlı seçim rehberi

Senaryo	Öneri
Basit public API	Fixed/Sliding Window
Mobil uygulama + ani burst	Token Bucket
Kuyruklayıp stabil yanıt üretmek	Leaky Bucket
Plan bazlı kota (free/pro)	Sliding + quota

---

Rate Limiting’i Nerede Uygulamalı? (Edge vs Uygulama)

Rate limiting’i iki temel noktada uygulayabilirsiniz:

Edge (Nginx/Ingress/API Gateway)

• Avantaj: Uygulamaya girmeden keser, daha ucuz
• Dezavantaj: Kullanıcı bazlı (JWT claim) gibi iş kuralları zorlaşabilir

Uygulama katmanı (Node.js, Django, Spring)

• Avantaj: Kullanıcı/tenant planı gibi kuralları rahat uygular
• Dezavantaj: Trafik uygulamaya ulaşır (yine de korur, ama maliyet artabilir)

Pratik öneri:

• Public endpoint’ler için edge’de kaba limit
• Auth’lu endpoint’ler için uygulamada ince ayar

---

HTTP 429 ve Doğru Header’lar

Rate limiting aktif olduğunda genellikle şu döner:

• HTTP 429 Too Many Requests

Ek olarak istemciye ne zaman tekrar denemesi gerektiğini söylemek iyi pratiktir:

• Retry-After: 10 (10 saniye sonra dene)

Bazı sistemler limit bilgisini header’larda taşır:

• X-RateLimit-Limit
• X-RateLimit-Remaining
• X-RateLimit-Reset

Bunu neden yapmalıyım? Çünkü istemci tarafında doğru retry/backoff davranışı oluşur. Aksi halde istemci daha da agresif retry yapabilir.

---

Nginx ile Rate Limiting (Hızlı Kurulum)

Nginx üzerinde IP bazlı bir limit örneği:

# http bloğu içinde
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;

server {
  location /api/ {
    limit_req zone=api_limit burst=10 nodelay;
    proxy_pass http://your_upstream;
  }
}

Açıklama:

• rate=5r/s: saniyede 5 istek
• burst=10: kısa süreli 10 isteğe kadar yığılma toleransı
• nodelay: burst içindeki istekleri geciktirmeden geçirir (daha agresif)

Ne zaman yeterli?

• Public endpoint’lerde botları ve ani patlamaları “ilk kapıda” kesmek için.

---

Node.js (Express) ile Rate Limiting (Uygulama Katmanı)

Aşağıdaki örnek, Express üzerinde IP bazlı basit bir rate limit uygular. Üretimde genellikle Redis backing store ile cluster/çoklu instance uyumlu hale getirilir.

1) Kurulum

npm i express express-rate-limit

2) Uygulama

import express from "express";
import rateLimit from "express-rate-limit";

const app = express();

// 1 dakikada 60 istek
const limiter = rateLimit({
  windowMs: 60 * 1000,
  limit: 60,
  standardHeaders: true, // RateLimit-* header'ları
  legacyHeaders: false,
  message: {
    error: "Too many requests",
    detail: "Lütfen biraz bekleyip tekrar deneyin."
  }
});

app.use("/api", limiter);

app.get("/api/health", (req, res) => {
  res.json({ ok: true });
});

app.listen(3000, () => console.log("Server running"));

3) Kullanıcı bazlı (API key) limit fikri

IP bazlı limit her zaman adil değildir (NAT arkasındaki kullanıcılar). Bu yüzden API key / user ID bazlı rate limiting daha doğru olabilir.

• API key’i header’dan okuyun
• Key’e göre sayaç tutun (Redis gibi)

Bunu neden yapmalıyım? Çünkü “aynı IP’den gelen 100 farklı gerçek kullanıcı” ile “tek kullanıcı botu” ayrıştırılır.

---

Gerçek Hayat Senaryosu: Giriş (Login) Endpoint’ini Korumak

En çok saldırı alan yerlerden biri /login veya OTP endpoint’leridir.

Önerilen yaklaşım:

1. IP bazlı rate limiting (edge’de)
2. Kullanıcı bazlı rate limiting (uygulamada)
3. Başarısız denemelerde progressive delay (ör. 1s → 2s → 4s)
4. Gerekirse captcha / device fingerprint

Örnek politika:

• IP başına: dakikada 20 deneme
• Kullanıcı/email başına: 10 dakikada 5 deneme

Bu kombinasyon, brute-force denemelerini ciddi şekilde azaltır.

---

Adım Adım Uygulama Planı (Pratik Checklist)

Rate limiting’i “hemen” devreye almak için:

1. Kritik endpoint’leri çıkarın: /login, /search, /signup, /checkout, pahalı raporlar
2. İlk aşamada edge’de kaba limit koyun (Nginx/Ingress)
3. Auth sonrası endpoint’lere kullanıcı/tenant bazlı limit ekleyin
4. 429 + Retry-After standardını uygulayın
5. Log/metric ekleyin:
   • Kaç istek 429 aldı?
   • En çok limit yiyen endpoint hangisi?
6. Limitleri “körlemesine” artırmayın: önce istemci hatası mı bot mu anlayın

---

Sık Sorulan Sorular (FAQ)

1) Rate limiting DDoS’u tamamen engeller mi?

Hayır. Rate limiting etkiyi azaltır ama büyük DDoS için CDN/WAF (Cloudflare gibi), network katmanı korumaları gerekir.

2) IP bazlı limit yeterli mi?

Public API’lerde başlangıç için iyi; ama NAT, proxy ve mobil operatörler yüzünden adil olmayabilir. Mümkünse API key / user ID bazlı limit ekleyin.

3) 429 dönerken ne göndermeliyim?

En azından 429 ve mümkünse Retry-After header’ı. Body’de kısa bir hata mesajı yeterli.

4) Limitleri nasıl belirlemeliyim?

Önce ölçün: normal kullanıcı dakikada kaç istek atıyor? Sonra %95 persentil davranışın biraz üstüne limit koyun. Plan bazlı farklılaştırın.

5) Rate limiting mi, quota mı?

Rate limiting “hız” (örn. dakikada 60), quota ise “toplam hak” (örn. ayda 10.000 istek). Birçok API ikisini birlikte kullanır.

---

Sonuç

Rate limiting, API’nizi hem kötüye kullanıma hem de beklenmedik trafik patlamalarına karşı koruyan en hızlı ve en etkili önlemlerden biridir. Bu yazıda rate limiting’in ne olduğunu, temel algoritmaları, Nginx’te edge seviyesinde ve Node.js’te uygulama seviyesinde nasıl devreye alınacağını gördünüz.

Siz hangi endpoint’te en çok abuse görüyorsunuz? Yorumlara yazın; kullandığınız stack’i (Nginx/Kubernetes/Node/.NET) söylerseniz size uygun bir limit politikası önerebilirim. Yazıyı ekip arkadaşlarınızla paylaşın ve bugün en az bir kritik endpoint’e rate limit ekleyip test edin.