API Gateway ve Rate Limiting Nedir?

Monolitik bir yazılımı on beş ayrı mikroservise (Kullanıcı, Sipariş, Sepet, Ödeme, Katalog, Bildirim, Stok...) böldüğünüzde, arka uçtaki geliştirme bağımsızlığını kazanırsınız; ancak dış dünyadaki istemciler (mobil uygulamalar, web tarayıcıları, üçüncü parti iş ortakları) için devasa bir karmaşıklık yaratırsınız. Eğer mobil uygulamanız doğrudan 15 farklı mikroservisin iç IP adresine ve portuna istek atarsa; her mikroserviste ayrı ayrı JWT kimlik doğrulaması, SSL/TLS sonlandırma, CORS kuralları ve DDoS koruması yazmak zorunda kalırsınız. Üstelik kötü niyetli bir bot veya hatalı yazılmış bir `while(true)` döngüsü saniyede 50.000 istek gönderdiğinde tüm veritabanı havuzunuz kilitlenir. İşte bu kaosu önleyen, dış dünya ile iç mikroservis ağı arasındaki tek giriş kapısı (Single Point of Entry) olan mimari katmana API Gateway (API Ağ Geçidi), sistemi aşırı yüklenmeye karşı koruyan trafik kontrol mekanizmasına ise Rate Limiting (Hız Sınırlama) adı verilir. Modern uygulama ve yazılım mühendisliğinde bu iki kavram, yüksek erişilebilirliğin (High Availability) sigortasıdır.

Bu kapsamlı mühendislik rehberinde; Kong, Envoy Proxy, AWS API Gateway ve NGINX gibi endüstri standardı ağ geçitlerinin iç mimarisini, Redis Lua betikleriyle uygulanan Token Bucket, Leaky Bucket, Fixed Window ve Sliding Window hız sınırlama algoritmalarını, BFF (Backend-for-Frontend) desenini ve zincirleme çökmeleri (cascading failures) durduran Circuit Breaker (Devre Kesici) mekanizmasını tüm teknik ayrıntılarıyla inceleyeceğiz.

1. API Gateway (API Ağ Geçidi) Nedir ve Hangi Sorumlulukları Üstlenir?

API Gateway, istemcilerden gelen tüm HTTP/HTTPS, gRPC veya WebSocket çağrılarını karşılayan, güvenlik ve trafik politikalarını uyguladıktan sonra isteği içerideki ilgili mikroservise (Upstream Service) yönlendiren ters vekil (Reverse Proxy) tabanlı bir yönetim katmanıdır. Klasik bir L4/L7 yük dengeleyiciden (Load Balancer) çok daha fazlasıdır; çünkü uygulama katmanı (Layer 7) iş mantığını ve API sözleşmelerini anlar.

Kurumsal bir API Gateway katmanının üstlendiği temel çapraz kesit sorumluluklar (Cross-Cutting Concerns) şunlardır:

• Merkezi Kimlik Doğrulama ve Yetkilendirme (AuthN & AuthZ): OAuth2, OpenID Connect (OIDC), API Anahtarı (API Key) ve JWT imza doğrulaması (JWKS kontrolü) ağ geçidinde yapılır. Geçersiz token taşıyan istekler iç mikroservislere hiç ulaşmadan kapıdan çevrilir (`401 Unauthorized`).
• Protokol Dönüşümü (Protocol Translation): Dış dünyadaki tarayıcıya standart JSON/REST veya GraphQL sunarken, içerideki mikroservislerle yüksek hızlı ikili (binary) gRPC (Protocol Buffers) üzerinden konuşabilir.
• İstek Birleştirme (Request Aggregation) ve BFF: Bir ürün detay ekranı için Katalog, Fiyat ve Yorum servislerine 3 ayrı mobil istek atmak yerine, API Gateway tek bir isteği alıp içeride paralel çağrılar yaparak birleştirilmiş tek bir JSON yanıtı dönebilir.
• Gözlemlenebilirlik (Observability) ve Dağıtık İzleme: Her isteğe benzersiz bir `X-Correlation-ID` veya OpenTelemetry izleme başlığı (`traceparent`) ekleyerek Prometheus metriklerini ve erişim loglarını merkezi olarak toplar.

Özellikle yüksek trafikli e-ticaret API ve webhook mimarilerinde ağ geçidi, hem iç ağ topolojisini dış dünyadan gizler hem de kanarya dağıtımlarını (Canary Deployment - trafiğin %5'ini v2 servisine, %95'ini v1 servisine yönlendirme) tek bir yapılandırma satırıyla mümkün kılar.

2. Rate Limiting (Hız Sınırlama) Nedir? Neden Hayati Önem Taşır?

Rate Limiting (Hız Sınırlama), bir kullanıcının, IP adresinin, API anahtarının veya kurumsal müşterinin (tenant) belirli bir zaman dilimi içinde (örneğin 1 dakikada veya 1 saniyede) yapabileceği maksimum istek sayısını sınırlandıran savunma mekanizmasıdır. Sınırı aşan istemcilere HTTP standardı olarak `429 Too Many Requests` durum kodu ve ne kadar süre beklemeleri gerektiğini belirten `Retry-After` başlığı döndürülür.

Hız sınırlamanın dört temel amacı vardır:

1. DDoS, Brute-Force ve Veri Kazıma (Scraping) Koruması: Saldırganların `/login` uç noktasına saniyede binlerce şifre denemesi yapmasını veya rakip botların tüm ürün fiyat kataloğunuzu kazımasını engeller.
2. Gürültülü Komşu (Noisy Neighbor) Etkisini Önleme: Çok kiracılı (Multi-tenant) SaaS platformlarında tek bir müşterinin hatalı entegrasyonunun diğer tüm müşterilerin hizmetini yavaşlatmasını önler.
3. Bulut Faturası ve Yapay Zeka Maliyet Kontrolü: Özellikle arka planda ücretli üçüncü parti API'ler, SMS ağ geçitleri veya GPU tabanlı LLM modelleri çalıştıran uç noktalarda bütçe patlamalarını durdurur.
4. API Gelir Modeli (Tiered Monetization): Ücretsiz pakette dakikada 60 istek, Kurumsal (Enterprise) pakette dakikada 10.000 istek hakkı tanımlayarak SaaS paketlendirmesini doğrudan altyapı seviyesinde uygular.

3. 4 Temel Rate Limiting Algoritması: Matematiksel ve Mimari Analiz

Bir hız sınırlayıcı tasarlarken seçeceğiniz algoritma; anlık trafik sıçramalarına (burst) izin verip vermeyeceğinizi ve sunucu başına ne kadar RAM tüketeceğinizi belirler.

1. Token Bucket (Jeton Kovası Algoritması)

Endüstride en yaygın kullanılan (AWS API Gateway ve Stripe'ın tercih ettiği) algoritmadır. Her kullanıcı için maksimum kapasitesi $B$ (örneğin 100 jeton) olan sanal bir kova düşünülür. Kovaya her saniye sabit bir $R$ hızında (örneğin saniyede 10 jeton) yeni jeton eklenir. Bir istek geldiğinde kovadan 1 jeton alınır; kova boşsa istek reddedilir (`429`). En büyük avantajı: Kullanıcının kısa süreli meşru trafik patlamalarına (burst - örneğin sayfa ilk açıldığında aynı anda atılan 20 API isteğine) kova kapasitesi kadar izin verirken, uzun vadeli ortalama hızı $R$ seviyesinde tutmasıdır.

2. Leaky Bucket (Sızdıran Kova Algoritması)

Altında küçük bir delik olan kova gibidir (FIFO kuyruğu). İstekler kovaya hangi hızla gelirse gelsin, kovadan dışarıya (mikroservise) tamamen sabit bir hızda damlar. Kova taşarsa yeni gelen istekler reddedilir. Trafik dalgalanmalarını tamamen düzleştirmek (traffic shaping) ve arka uçtaki hassas bir eski (legacy) sistemi sabit hızda beslemek için idealdir; ancak anlık patlamalarda kullanıcıyı kuyrukta beklettiği için yanıt süresini artırabilir.

3. Fixed Window Counter (Sabit Pencere Sayacı)

Zamanı sabit dilimlere böler (örneğin `14:00:00 - 14:01:00` arası 1. pencere) ve Redis'te `INCR user:123:1400` komutuyla tek bir tam sayı tutar. Uygulaması çok basittir; ancak ciddi bir Sınır Kenarı Sorunu (Boundary Burst Problem) vardır: Dakikada 100 istek hakkı olan bir kullanıcı, `14:00:59`'da 100 istek ve hemen 2 saniye sonra `14:01:01`'de 100 istek daha atarsa, 2 saniye içinde 200 istek geçirerek limiti ikiye katlamış olur!

4. Sliding Window Log & Sliding Window Counter (Kayan Pencere)

Sabit pencerenin sınır kenarı açığını kapatır. Sliding Window Log her isteğin zaman damgasını (timestamp) bir Redis Sorted Set (`ZADD`) içinde tutar ve son 60 saniye dışındakileri (`ZREMRANGEBYSCORE`) silip kalan eleman sayısını (`ZCARD`) ölçer. %100 kesindir. Daha az bellek tüketen Sliding Window Counter ise önceki pencerenin ağırlıklı ortalamasıyla mevcut pencerenin sayacını birleştirerek Cloudflare ölçeğinde hem hafif hem de hassas koruma sağlar.

// Node.js + Redis Lua Script: Atomik Token Bucket Hız Sınırlayıcı (Race Condition Önleyici)
import Redis from "ioredis";
const redis = new Redis(process.env.REDIS_URL!);

const TOKEN_BUCKET_LUA = `
local key = KEYS[1]
local capacity = tonumber(ARGV[1])
local refill_rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])

local bucket = redis.call("HMGET", key, "tokens", "last_refill")
local tokens = tonumber(bucket[1])
local last_refill = tonumber(bucket[2])

if tokens == nil then
  tokens = capacity
  last_refill = now
else
  local elapsed = math.max(0, now - last_refill)
  tokens = math.min(capacity, tokens + (elapsed * refill_rate))
  last_refill = now
end

if tokens >= 1 then
  tokens = tokens - 1
  redis.call("HMSET", key, "tokens", tokens, "last_refill", last_refill)
  redis.call("EXPIRE", key, math.ceil(capacity / refill_rate) * 2)
  return { 1, math.floor(tokens) }
else
  return { 0, 0 }
end
`;

export async function checkRateLimit(clientId: string) {
  const nowInSeconds = Date.now() / 1000;
  const [allowed, remaining] = (await redis.eval(
    TOKEN_BUCKET_LUA,
    1,
    `rl:bucket:${clientId}`,
    50,  // Maksimum Kova Kapasitesi (Burst = 50 istek)
    5,   // Saniyede Dolum Hızı (5 jeton/sn)
    nowInSeconds
  )) as [number, number];

  return { allowed: allowed === 1, remaining };
}

Neden Redis Lua Script Kullanmalıyız? Eğer Redis'ten önce bakiyeyi okuyup (`GET`), uygulama kodunda azaltıp tekrar yazarsanız (`SET`), aynı milisaniyede gelen 10 paralel istek aynı bakiyeyi okur (Race Condition) ve limiti deler. Lua betiği Redis’in tek iş parçacıklı motorunda atomik olarak çalıştığı için yarış durumu ihtimali sıfırdır.

4. Circuit Breaker (Devre Kesici) ve BFF (Backend-for-Frontend) Desenleri

Rate Limiting sisteminizi dışarıdan gelen aşırı trafiğe karşı korurken, Circuit Breaker (Devre Kesici) sisteminizi içerideki bozuk veya yavaşlamış bir mikroservise karşı korur. Elektrik tesisatındaki sigorta gibi çalışan Devre Kesici üç durumda (State Machine) bulunur:

• Closed (Kapalı - Normal Akış): Tüm istekler alt mikroservise (örneğin Kargo Hesaplama Servisi) normal şekilde iletilir.
• Open (Açık - Sigorta Attı): Eğer Kargo Servisi üst üste %50 hata vermeye veya 10 saniye zaman aşımına (timeout) düşmeye başlarsa, API Gateway sigortayı attırır (Open). Artık 30 saniye boyunca Kargo Servisine hiçbir istek gönderilmez; anında önbellekteki varsayılan kargo ücreti (Fallback Response) dönülür. Böylece Kargo Servisinin yavaşlığı yüzünden tüm Sipariş sunucularının iş parçacıklarının (thread pool) tıkanıp tüm sitenin çökmesi (Cascading Failure) engellenir ve genel site yanıt hızı korunur.
• Half-Open (Yarı Açık - Test Durumu): 30 saniye dolduğunda ağ geçidi yalnızca birkaç deneme isteğini servise gönderir; başarılı olursa sigortayı tekrar Closed durumuna alır.

Buna ek olarak, mobil uygulama (iOS/Android), masaüstü web sitesi ve akıllı saat uygulamasının veri ihtiyaçları birbirinden tamamen farklıdır. Tek bir dev API Gateway yerine her istemci türü için özelleşmiş hafif bir ağ geçidi kurgulama yaklaşımına BFF (Backend-for-Frontend) adı verilir.

5. Kuzey-Güney (North-South) ve Doğu-Batı (East-West) Trafik: API Gateway vs Service Mesh

Bulut-yerel (cloud-native) mimari tasarımlarında ağ trafiği iki ana eksende sınıflandırılır ve her iki eksen için farklı kontrol katmanları kullanılır:

• Kuzey-Güney (North-South) Trafiği ve API Gateway: Dış dünyadaki (internet) istemcilerden veri merkezinize veya Kubernetes kümenize giren ve çıkan trafiktir. Kenar güvenlik (WAF, DDoS koruması), genel SSL sonlandırma, müşteri bazlı Rate Limiting ve OAuth2/JWT doğrulaması bu sınır kapısında (Edge API Gateway) yönetilir.
• Doğu-Batı (East-West) Trafiği ve Service Mesh (Hizmet Ağı): Küme içindeki mikroservislerin kendi aralarında yaptığı (`Sipariş Servisi -> Ödeme Servisi -> Stok Servisi`) iç iletişimdir. Eğer küme içindeki her mikroservis çağrısını tekrar en baştaki merkezi API Gateway'e gönderirseniz gereksiz bir ağ sıçraması (network hop) ve darboğaz yaratırsınız. Bunun yerine Istio, Linkerd veya Cilium gibi bir Service Mesh kullanılarak her podun yanına hafif bir Envoy vekili (Sidecar) veya eBPF katmanı yerleştirilir ve servisler arası mTLS (Karşılıklı TLS Şifreleme) ile sıfır güven (Zero-Trust) politikaları iç ağda uygulanır.

Ayrıca modern Kubernetes ekosisteminde eski `Ingress` kaynağının yerini alan yeni nesil Kubernetes Gateway API standardı; altyapı sağlayıcıları, platform mühendisleri ve uygulama geliştiricileri arasında rol tabanlı yetki ayrımı yaparak hem HTTP başlık yönlendirmesini hem de trafik bölme (Traffic Splitting) ve hız sınırlama kurallarını taşınabilir tek bir YAML şemasında birleştirmiştir.

6. Popüler API Gateway Çözümleri Karşılaştırma Tablosu

Altyapınız için doğru API ağ geçidini seçerken aşağıdaki mimari karşılaştırma tablosunu referans alabilirsiniz:

API Gateway Çözümü	Temel Teknoloji	Performans ve Gecikme	Öne Çıkan Güçlü Yönü
Kong Gateway	NGINX + OpenResty (Lua / Go)	Çok Yüksek (<1-2 ms ek yük)	Zengin hazır eklenti (Plugin) ekosistemi, kurumsal olgunluk
Envoy Proxy / Istio	C++ (Modern L7 Proxy)	Ultra Yüksek (Düşük bellek)	Kubernetes Service Mesh, gRPC, HTTP/3 ve dinamik xDS yapılandırması
AWS API Gateway	Tam Yönetilen Bulut Servisi	Yüksek (Serverless entegre)	Sıfır sunucu bakımı, AWS Lambda ve IAM ile doğrudan entegrasyon
Apache APISIX	NGINX + etcd (Lua)	Ultra Yüksek	Yeniden başlatma gerektirmeyen (hot-reload) milisaniyelik kural değişimi
KrakenD	Go (Golang)	Çok Yüksek (Durumsuz/Stateless)	Çoklu mikroservis yanıtlarını birleştirme (Aggregation / BFF) hızı

6. Sıkça Sorulan Sorular (SSS)

1. Ters Vekil (Reverse Proxy - NGINX) ile API Gateway arasındaki fark nedir?

NGINX veya HAProxy gibi bir Reverse Proxy temel olarak ağ yönlendirmesi, SSL sonlandırma ve statik önbellekleme yapar. Bir API Gateway ise bunun üzerine OAuth2/JWT doğrulama, kullanıcı/paket bazlı Rate Limiting, istek/yanıt gövdesi dönüştürme, faturalandırma analitiği ve geliştirici portalı gibi API'ye özgü iş mantığı katmanlarını ekler.

2. Rate Limiting sadece IP adresine göre yapılırsa ne gibi sorunlar çıkar?

Üniversite kampüsleri, kurumsal şirket ofisleri, devlet kurumları ve mobil operatörler (CGNAT) binlerce gerçek kullanıcıyı tek bir ortak genel IP adresi (Public IP) arkasından internete çıkarır. Eğer hız sınırlamayı yalnızca IP adresine göre yaparsanız, aynı şirketteki 50 çalışan sitenize girdiğinde hepsini bloklarsınız! Bu nedenle giriş yapmış kullanıcılarda User ID / API Key, giriş yapmamış kullanıcılarda ise IP + Tarayıcı Parmak İzi (JA3/JA4 TLS Fingerprint) kombinasyonu kullanılmalıdır.

3. İstemciye hız sınırına yaklaştığını hangi HTTP başlıklarıyla bildirmeliyiz?

IETF standart taslağına göre her API yanıtında istemciye şu üç başlığı dönmek iyi bir mühendislik pratiğidir: `X-RateLimit-Limit` (toplam kota), `X-RateLimit-Remaining` (kalan istek hakkı) ve `X-RateLimit-Reset` (kotanın sıfırlanacağı UTC zaman damgası veya kalan saniye). Böylece iyi yazılmış istemci SDK'ları `429` hatası almadan önce kendi hızlarını otomatik yavaşlatabilir.

4. API Gateway tek hata noktası (Single Point of Failure - SPOF) oluşturmaz mı?

Eğer tek bir sunucu üzerinde çalıştırılırsa evet! Bu yüzden üretim ortamlarında API Gateway düğümleri her zaman durumsuz (stateless) olarak tasarlanır, birden fazla erişilebilirlik alanında (Multi-AZ) en az 3+ kopya (replica) halinde aktif-aktif (Active-Active) çalıştırılır ve durum verisi (Rate Limit sayaçları) yüksek erişilebilirlikli bir Redis Cluster kümesinde tutulur.

5. Rate Limiting (Hız Sınırlama) ile Throttling (Boğma/Yavaşlatma) arasındaki fark nedir?

Rate Limiting genellikle katı bir eşiktir; limit aşıldığında isteği `429` hatasıyla anında reddeder. Throttling ise isteği reddetmek yerine istemcinin hızını kademeli olarak yavaşlatma, kuyruğa alma veya bant genişliğini kısma stratejisidir. Ayrıca tersine mühendislik ve otomatik bot analizlerine karşı şüpheli istemcileri tamamen reddetmek yerine yanıt süresini kasıtlı olarak 3-5 saniyeye çıkaran Tarpitting tekniği de bir Throttling yöntemidir.