API ve Mikroservisler İçin Rate Limiting Stratejileri: Nginx, Cloudflare ve Redis ile Trafik Kontrolü

API ve mikroservislerde rate limiting neden bu kadar kritik?

API tasarlarken çoğu ekip önceliği doğrulama, veritabanı modeli ve iş kurallarına verir. Trafik kontrolü ve rate limiting ise genellikle proje canlıya yaklaştığında, yük testleri veya maliyet analizi sırasında gündeme gelir. Oysa iyi tasarlanmış bir rate limiting stratejisi, hem performans hem güvenlik hem de altyapı maliyetleri açısından en az mimari seçimleriniz kadar belirleyicidir.

Örneğin çok kiracılı bir SaaS uygulaması geliştirdiğinizi düşünün. Aynı API üzerinde, ücretsiz plandaki binlerce küçük müşteri ile yüksek hacimli kurumsal müşteriler aynı altyapıyı kullanıyor. Doğru rate limit politikaları tanımlamazsanız, tek bir agresif istemci veritabanınızı kilitleyebilir, diğer tüm müşterileriniz yavaşlayan API yüzünden şikayet etmeye başlayabilir. Üstelik bu durum ek CPU, RAM ve bant genişliği maliyetlerine de yol açar.

Bu yazıda, DCHost altyapısında sıkça uyguladığımız yaklaşımlara dayanarak, Nginx, Cloudflare ve Redis kullanarak API ve mikroservisler için uçtan uca rate limiting mimarisi nasıl kurulur, adım adım ele alacağız. Temel modellerden, gerçek dünya senaryolarına; edge (Cloudflare) katmanından uygulama (Nginx) ve paylaşılan sayaç (Redis) tarafına kadar pratik olarak uygulayabileceğiniz bir çerçeve çizmeye çalışacağım.

Rate limiting temelleri: Ne sınırlanır, nasıl sınırlanır?

Rate limiting kabaca, belirli bir süre aralığında belirli bir kaynaktan gelen istek sayısını sınırlama işlemidir. Ancak pratikte, neyi ve neyin üzerinden sınırladığınız en az limit değerleri kadar önemlidir.

Hangi anahtara göre limit?

• IP bazlı: En basit ve yaygın yöntemdir. Aynı IP adresinden gelen istekleri sınırlarsınız. Avantajı kolay uygulanması; dezavantajı ise NAT, kurumsal ağlar ve mobil operatörlerde çok sayıda kullanıcının aynı IP altından gelmesidir.
• Kullanıcı/oturum bazlı: JWT, session id veya kullanıcı id üzerinden limit koyarsınız. Kimlik doğrulaması olan API’ler için daha adil bir model sunar.
• API anahtarı / client id bazlı: Üçüncü taraf entegrasyonlar, partner API’ler ve multi-tenant SaaS senaryolarında idealdir. Her müşteriye ayrı kota ve hız sınırı tanımlanabilir.
• Endpoint bazlı: Özellikle maliyetli işlemler (rapor üretme, dış servis çağrıları, ödeme adımları) için yol/route bazlı ek limit koymak çok işe yarar.

Hangi matematiksel model?

• Fixed window (sabit pencere): Dakikada 100 istek gibi, belirli zaman pencerelerinde sayaç sıfırlanır. Basit ama sınırın hemen öncesi ve sonrasında patlama etkisi olabilir.
• Sliding window (kayan pencere): Gerçek zamanlı olarak son X saniyedeki istekleri hesaplar. Daha adil fakat uygulaması biraz daha karmaşıktır.
• Token bucket: Belirli hızda kova içine token eklenir, her istek bir token harcar. Ani küçük patlamalara izin verir, uzun vadede hızı kontrol altında tutar.
• Leaky bucket: Kova belirli sabit hızla boşalır, gelen istekler kuyruğa alınır. Taşma olduğunda istekler reddedilir.
• Eş zamanlı bağlantı (concurrency) limiti: Özellikle uzun süren istekler için, aynı anda açık olabilecek istek sayısını sınırlar.

Nginx tarafında çoğunlukla fixed window + burst yaklaşımı, Redis ile ise sliding window veya token bucket modelini uygulamak pratik bir kombinasyondur.

Mimari kararlar: Rate limiting nerede uygulanmalı?

Modern bir API mimarisinde çoğunlukla üç katmanınız olur: edge (CDN/WAF), reverse proxy/API gateway (Nginx vb.) ve uygulama/mikroservis katmanı. Rate limiting bu katmanların her birinde farklı amaçlarla konumlandırılabilir.

1. Edge katmanı: Cloudflare ile ilk savunma hattı

Cloudflare gibi bir CDN/WAF katmanı, trafiğinize en dıştan bakan noktadır. Burada yapılan rate limiting genellikle:

• DDoS benzeri yüksek hacimli saldırıları uygulama sunucusuna ulaşmadan kesmek,
• Basit bot ve tarayıcıları yavaşlatmak ya da engellemek,
• Belirli ülke, ASN veya IP kümelerinden gelen trafiği sıkılaştırmak

için kullanılır. Cloudflare tarafındaki WAF ve rate limit ayarlarını adım adım ele aldığımız Cloudflare güvenlik ayarları rehberine mutlaka göz atmanızı öneririm.

2. Reverse proxy katmanı: Nginx ile uygulama önünde ince ayar

Nginx, hem klasik monolit PHP uygulamalarında hem de mikroservis tabanlı yapılarda API gateway veya reverse proxy olarak konumlanabiliyor. Bu katmanda rate limiting ile:

• Her IP veya kullanıcı için saniye/dakika bazında istek hızını sınırlayabilir,
• Belirli endpoint’ler (örneğin /login, /password-reset, ödeme adımları) için daha sıkı limitler tanımlayabilir,
• Uzun süren istekler için eş zamanlı bağlantı sayısını kontrol edebilirsiniz.

Nginx modülleri ile rate limiting konusuna WordPress odaklı olarak girdiğimiz Nginx rate limiting ve Fail2ban rehberinde mantığın nasıl çalıştığını, saldırı senaryoları üzerinden anlatmıştık.

3. Paylaşılan sayaç katmanı: Redis ile dağıtık limit

API’niz birden fazla uygulama sunucusunda, hatta farklı veri merkezlerinde çalışıyorsa, her node’un kendi belleğinde tuttuğu sayaçlar yeterli olmaz. Bu durumda devreye Redis tabanlı merkezi rate limiting girer:

• Tüm API sunucuları aynı Redis kümesine bağlanır.
• Her istek için ilgili anahtar (örneğin müşteri id + endpoint) üzerinden sayaç artırılır.
• Zaman penceresi ve limit kontrolü Redis üzerinde (çoğunlukla Lua script’leri ile) yapılır.

Redis altyapısının performans tarafını daha geniş açıdan anlattığımız Redis cache ve hosting performansı rehberimiz, burada kullanacağınız Redis kümesini tasarlarken de işinize yarayacaktır.

Cloudflare ile edge rate limiting tasarımı

Cloudflare’da rate limiting politikası oluştururken önce neyi hedeflediğinizi netleştirmeniz gerekir. Edge katmanında yaptığınız her kontrol, uygulama sunucularınıza gitmeyen istek sayısını artırır; yani hem güvenlik hem de maliyet açısından kazanırsınız.

Tipik kullanım senaryoları

• Login ve brute-force saldırıları: /login, /wp-login.php, /api/auth gibi endpoint’lere saniyede X isteğin üzerinde gelen IP’leri geçici olarak engellemek.
• Scraping ve bot trafiği: Aynı IP’nin kısa sürede çok sayıda farklı URL isteğinde bulunması durumunda challenge veya yavaşlatma uygulamak.
• Belli ülke veya ASN kaynaklı trafik: Örneğin ödeme API’nize sadece belirli ülkelerden erişim bekliyorsanız, diğer ülkeler için çok daha sıkı limitler koymak.

Basit bir rate limit kuralı mantığı

Cloudflare panelinde tipik bir kural kurgusu şu şekilde olur:

• Expression: (http.request.uri.path contains ‘/api’) and (ip.src ne belirli whitelist’te)
• Eşik: 60 saniyede 120 istek
• Aksiyon: 429 döndür veya yönetimli challenge uygula
• Süre: 10 dakika boyunca kural ihlal eden IP’ye uygulansın

Önemli nokta, burada uyguladığınız limitin kaba bir koruma olduğu gerçeğini unutmamak. Cloudflare tarafında API’nizin temel güvenliğini ve kaba saldırıları süzgeçten geçirirken, daha ince taneli müşteri bazlı limitleri Nginx ve Redis katmanında bırakmak genellikle en sağlıklı yaklaşımdır.

Nginx ile uygulama önünde rate limiting

Nginx, hem basit IP bazlı limitler hem de daha gelişmiş anahtar kombinasyonları ile rate limiting için güçlü araçlar sunar. En çok kullanılan modül limit_req_module‘dür.

Temel IP bazlı rate limit örneği

http {
    # 1 saniyede 5 istek, burst ile kısa süreli 10 isteğe izin
    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://backend_api;
        }
    }
}

Burada:

• $binary_remote_addr ile anahtar olarak IP adresi kullanıyoruz.
• rate=5r/s saniyede 5 istek anlamına geliyor.
• burst=10 kısa süreli ani patlamalara (örneğin kullanıcı tarayıcıdan hızlıca birkaç butona bastığında) izin veriyor.
• nodelay opsiyonu, burst limitini aşan istekleri direkt reddetmek yerine sıraya sokmak veya hemen hata döndürmek konusunda davranışı etkiliyor.

Kullanıcı veya API anahtarı bazlı limit

Daha adil bir model için, IP yerine API anahtarı veya kullanıcı id bazlı rate limit uygulayabilirsiniz. Örneğin her istekte gelen X-Api-Key başlığını kullanmak:

map $http_x_api_key $api_key {
    default $http_x_api_key;
    ''      $binary_remote_addr;  # header yoksa IP'ye düş
}

limit_req_zone $api_key zone=api_key_limit:20m rate=60r/m;

server {
    location /api/ {
        limit_req zone=api_key_limit burst=20 nodelay;
        proxy_pass http://backend_api;
    }
}

Bu yaklaşım sayesinde, aynı IP’den gelen farklı API anahtarlarını birbirinden bağımsız olarak sınırlayabilirsiniz. Özellikle mikroservis mimarisinde, her müşteri veya partner için ayrı API anahtarı veriyorsanız, bu model oldukça pratik çalışır.

Belirli endpoint’ler için daha sıkı limitler

Her endpoint eşit maliyetli değildir. Örneğin rapor üreten veya dış sistemlerle konuşan bir /api/report endpoint’i, basit bir /api/profile isteğinden çok daha ağır olabilir. Nginx tarafında sadece bu endpoint’e özel ek limit ekleyebilirsiniz:

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

server {
    location /api/report {
        limit_req zone=report_limit burst=5;
        proxy_pass http://backend_api;
    }
}

Bu sayede kullanıcılarınız profil verisini hızlı çekmeye devam ederken, maliyetli rapor isteklerine yük dengesini koruyacak şekilde sınır koyabilirsiniz.

429 yanıtlarını doğru yönetmek

Rate limit aşıldığında sunucunun verdiği yanıt genellikle 429 Too Many Requests olur. Bu yanıtın:

• İçeriğinde kullanıcıya net ve nazik bir mesaj bulunması,
• Geri dönüş süresini belirten Retry-After başlığının yer alması,
• Uygulama log’larında anlamlı şekilde işaretlenmesi

müşteri deneyimi ve hata analizi için çok değerlidir. 4xx ve 5xx hata kodlarını Nginx log’larından nasıl okuyacağınızı anlattığımız sunucu loglarını okuma rehberimiz, burada da işinizi epey kolaylaştıracaktır.

Redis ile dağıtık rate limiting: Gerçek çok sunuculu senaryolar

DCHost üzerinde çok sayıda API’yi, birden fazla VPS veya dedicated sunucuya yayılmış şekilde çalıştıran müşterilerimiz var. Bu tür ortamlarda Nginx’in kendi bellek içi sayaçları node bazında kalır; yani aynı IP, farklı node’lara düştüğünde limit doğru çalışmaz. İşte bu noktada Redis ile merkezi rate limiting mantığı devreye girer.

Neden Redis?

• Tek merkezi sayaç: Tüm uygulama pod’ları veya sunucuları aynı Redis kümesine bağlanır.
• Yüksek performans: Bellek içi çalışma modeli sayesinde milisaniye seviyesinde cevap verir.
• Gelişmiş script olanakları: Lua script’leriyle sliding window veya token bucket modellerini atomic şekilde uygulayabilirsiniz.

Basit sliding window mantığı

Sliding window için tipik bir mantık şu şekildedir:

1. Her istek geldiğinde, Redis’te ilgili anahtar (örneğin rate:user_id) altında bir liste veya sorted set tutarsınız.
2. Şu andan X saniye öncesine ait kayıtları silersiniz.
3. Kalan eleman sayısı limitin altındaysa yeni isteği kabul edip zaman damgasını eklersiniz; üzerindeyse 429 dönersiniz.

Bunu Redis’te Lua script’i ile tek atomik işlem olarak çalıştırmak, yarış koşullarını (race condition) engeller ve tutarlı bir sonuç üretir.

Token bucket için Redis yaklaşımı

Token bucket modelinde mantık biraz farklıdır:

• Her kullanıcı veya API anahtarı için bir token sayacı saklanır.
• Zaman içerisinde belirli hızda (örneğin saniyede 5) yeni token eklenir.
• Her istek geldiğinde bir token tüketilir; token yoksa istek reddedilir.

Bu modeli uygularken genellikle sayaç yanında son güncelleme zamanını da saklar, yeni istek geldiğinde aradan geçen süreye göre eklenmesi gereken token sayısını hesaplarsınız. Tüm bu işlem de yine tek bir Lua script’i ile Redis üzerinde yapılabilir.

Nginx ile Redis’i konuşturmak

Eğer Nginx’te OpenResty veya lua-nginx-module kullanıyorsanız, rate limiting mantığının bir kısmını Lua kodu ile Nginx üzerinde çalıştırıp Redis’e bağlayabilirsiniz. Alternatif olarak, rate limiting tamamen uygulama kodu (Node.js, Laravel, Go vb.) içinde yapılıp yalnızca Redis paylaşılan sayaç olarak kullanılabilir.

Önemli olan, tüm sunucuların aynı veri kaynağını kullanması ve bu veri kaynağına erişimin gecikme ve hata durumlarında ne olacağını net tanımlamanızdır. Redis kümenizin yüksek erişilebilirlik tasarımında, DCHost üzerinde ayrı bir Redis VPS’i veya ayrılmış bir Redis dedicated sunucusu konumlandırmak pratik bir çözüm olur.

Gerçek dünya senaryoları: Hangi API’ye nasıl limit koymalı?

Teoriden pratiğe geçelim. DCHost müşterilerinde sık gördüğümüz üç senaryo üzerinden ilerleyelim: herkese açık public API, çok kiracılı SaaS API’si ve iç mikroservis trafiği.

1. Public API: Anonim ve kimlikli erişim karışık

Örneğin şehir bazlı hava durumu veya döviz kuru sağlayan bir public API’niz olsun. Hem anonim erişime izin veriyorsunuz, hem de kayıtlı müşterileriniz var.

• Cloudflare katmanı: IP bazlı kaba rate limit (örneğin 1 dakikada 300 istek üzeri 10 dakikalık engel) ve WAF ile temel bot filtreleme.
• Nginx katmanı:
  • Anonim istekler için IP bazlı düşük limit (dakikada 30),
  • Kayıtlı müşteriler için X-Api-Key üzerinden daha yüksek ve paket bazlı limit (dakikada 600, 3000 vb.).
• Redis katmanı: Tüm Nginx node’ları, müşteri bazlı limitler için Redis’te merkezi sayaç kullanır. Sliding window ile daha adil dağılım sağlanır.

Bu mimaride, anonimler edge ve Nginx katmanında güçlü şekilde filtrelenirken, gelir getiren müşterileriniz için daha esnek ve müşteri planına göre ayarlanabilir bir limit modeliniz olur.

2. Çok kiracılı SaaS: Farklı paketler, farklı haklar

Örneğin bir CRM SaaS uygulamanız var ve Basic, Pro, Enterprise gibi katmanlarınız bulunuyor. Her plan için farklı API limiti vermek istiyorsunuz.

• Plan bazlı anahtar: Her müşteriye atadığınız client_id ile birlikte plan bilgisini de uygulamanız biliyor. Redis anahtarınızı plan + müşteri id şeklinde kurgulayabilirsiniz.
• Redis ile kota takibi: Sadece saniye/dakika değil, günlük ve aylık toplam istek sayısını da takip edip yumuşak ve sert limitler tanımlayabilirsiniz.
• Nginx ile hız kontrolü: Anlık hız limitlerine Nginx bakarken, toplam kota takip ve uyarı sistemini uygulama + Redis ikilisi yönetir.

Bu tip bir SaaS’te, DCHost üzerinde ayrı bir Redis VPS veya managed Redis kümesi konumlandırmak, hem performans hem de ölçeklenebilirlik açısından uzun vadede ciddi avantaj sağlar.

3. İç mikroservis trafiği: Sadece dış dünya değil

Mikroservis mimarisinde çoğu ekip rate limiting’i sadece dışarıya açık API’lerde düşünür. Oysa iç servisler arasında da yanlış yapılandırılmış bir batch job veya sonsuz döngü, diğer servisleri kilitleyebilir.

• Servis bazlı limit: Her mikroservis için bir client id tanımlayıp Redis üzerinden, çağırdığı servis başına limit koyabilirsiniz.
• Queue ve asenkron işlemler: Büyük hacimli işlerinizi queue sistemine (RabbitMQ, Kafka vb.) atıp, API üzerinden sadece tetikleme isteği alacak şekilde tasarlayarak, rate limiting baskısını azaltabilirsiniz.
• Gözlemlenebilirlik: İç servislerin birbirini nasıl çağırdığını görmek için log ve metrik toplayıp alarmlar kurmak çok kritik. Bu konuda VPS izleme ve alarm kurulum rehberimizde anlattığımız Prometheus/Grafana yaklaşımı mikroservisler için de birebir geçerlidir.

İzleme, loglama ve test: Limitleriniz gerçekten çalışıyor mu?

Rate limiting, bir kere ayarlayıp unutacağınız bir konu değildir. Yanlış kurgulanmış bir limit, gerçek saldırganları değil, en değerli müşterilerinizi engelleyebilir. Bu yüzden üç alanda sürekli gözünüzün açık olması gerekir: loglama, metrikler ve test.

Loglama

• 429 yanıtlarını ayrı bir log formatı veya ayrı bir dosyaya yazdırmak,
• Hangi endpoint, hangi anahtar ve hangi IP kombinasyonu ile limit aşıldığını kaydetmek,
• Redis tarafında script hata ve gecikmelerini izlemek

olası yanlış pozitifleri erken fark etmenizi sağlar. Nginx ve Apache log formatlarını nasıl okumanız gerektiğini detaylı anlattığımız log analizi rehberi, rate limiting hatalarını teşhis ederken doğrudan kullanılabilir.

Metrikler

• Toplam istek sayısı,
• 429 oranı (toplam isteğe oranla),
• Endpoint bazlı 429 dağılımı,
• Redis gecikme süreleri ve hata oranları

gibi metrikleri Prometheus ve Grafana ile toplayıp panellerde izlemek, limitlerinizin gerçek hayatta ne kadar agresif olduğunu görmenizi sağlar. Bu konuda giriş seviyesinde bir kurulum için VPS izleme rehberimize göz atabilirsiniz.

Test

Canlıya almadan önce mutlaka yük testi ve senaryo bazlı rate limit testi yapmanız gerekir:

• Anonim yüksek hacimli istekler ile Cloudflare ve Nginx limitlerini tetikleyin.
• Farklı planlardaki müşteriler için API anahtarı kullanarak Redis tabanlı limitlerin doğru çalıştığını doğrulayın.
• Uzun süreli yük altında, Redis ve Nginx node’larınızın kaynak kullanımını (CPU, RAM, IO) izleyin.

DCHost üzerindeki VPS ve dedicated sunucularınızı seçerken kapasite planlamasını doğru yapmak da burada önemli. Bu konuda hazırladığımız CPU, RAM ve trafik hesaplama yazılarımızı da mimarinizi planlama aşamasında gözden geçirmenizi öneririz.

DCHost altyapısında pratik rate limiting önerileri

DCHost olarak hem yüksek trafikli API projeleri hem de orta ölçekli SaaS uygulamaları için sıkça benzer mimariler kurguluyoruz. Saha deneyimimizden süzülen birkaç pratik tavsiyeyi özetleyelim.

Küçük ve orta ölçekli API projeleri

• Tek veya iki VPS ile başlıyorsanız, Nginx’in kendi limit_req ve limit_conn özellikleri çoğu zaman yeterlidir.
• Redis’i hemen oyuna almak yerine, önce Nginx tarafında IP ve kullanıcı bazlı basit limitlerle başlayın.
• Cloudflare’ı en azından temel WAF ve kaba rate limit için mutlaka devreye alın.

Büyüyen SaaS ve çok kiracılı mimariler

• Uygulama sunucularınızı ayrı VPS’lere, Redis’i ise ayrı bir VPS veya dedicated sunucuya taşıyın.
• Rate limiting mantığını kod tarafına değil, mümkün olduğunca Redis + Nginx kombinasyonuna taşıyın; böylece farklı teknoloji stack’lerine sahip mikroservisler bile ortak bir limit altyapısını kullanabilir.
• Müşteri paketlerinizi (Basic, Pro, Enterprise vb.) analiz edip, her biri için saniye, dakika ve aylık toplam istek limitlerini netleştirin.

Yüksek trafikli ve kritik API’ler

• En az iki farklı lokasyonda VPS veya dedicated sunucu ile yüksek erişilebilirlik senaryosu kurun.
• Cloudflare edge rate limiting + Nginx node başı limit + Redis merkezi limit üçlüsünü birlikte kullanın.
• Rate limiting kararlarınıza mutlaka iş birimi ile birlikte karar verin; bazı kurumsal müşterileriniz için daha esnek sınırlar, SLA ve faturalandırma ile bağlantılı olabilir.

Altyapınızı DCHost üzerinde planlarken, API ve mikroservis trafiğiniz için en uygun kombinasyonu birlikte tasarlayabilir, gerekirse VPS, dedicated sunucu ve colocation seçeneklerini aynı mimaride kullanabiliriz.

Sonuç ve yol haritası

Rate limiting, API veya mikroservis mimarinize sonradan ekleyeceğiniz küçük bir eklenti değil, baştan tasarımın parçası olması gereken temel bir bileşendir. Doğru kurgulandığında, saldırıları daha uygulamaya gelmeden Cloudflare katmanında durdurur, Nginx ile her endpoint’in hakkını verir, Redis ile de tüm node’larınızda tutarlı ve adil bir hız kontrolü sağlarsınız.

Özetle önerdiğimiz yol haritası şöyle:

• Önce iş ve trafik modellerinizi analiz edin; kim, neye, ne sıklıkta erişecek sorularına net cevap verin.
• Edge katmanında Cloudflare ile kaba rate limit ve WAF kurallarınızı oluşturun.
• Nginx üzerinde IP, kullanıcı veya API anahtarı bazlı temel limitleri tanımlayın; kritik endpoint’leri ayrıca ele alın.
• Altyapınız çok sunuculu hale geldiğinde Redis tabanlı merkezi rate limiting’e geçin ve sliding window/token bucket gibi daha gelişmiş modelleri kullanın.
• 429 oranlarını, Redis gecikmelerini ve endpoint bazlı limit ihlallerini sürekli izleyin; gerektiğinde limitleri kademeli olarak ayarlayın.

Eğer API veya mikroservis projenizi yeni planlıyorsanız ya da mevcut trafiğinizde zaman zaman boğulmalar yaşıyorsanız, DCHost ekibi olarak mimarinizi birlikte gözden geçirip Nginx, Cloudflare ve Redis ile size özel bir rate limiting stratejisi çıkarmaktan memnuniyet duyarız. Doğru tasarlanmış bir trafik kontrolü, yalnızca güvenliği değil, aynı zamanda müşteri memnuniyetini ve altyapı maliyetlerinizi de doğrudan iyileştirir.