Bir Bot Tüm Sistemi Nasıl Çökertti?
Bir bot veya hatalı istemci, birkaç dakika içinde API'yi kullanılamaz hale getirebilir. Bu yazıda Rate Limiting'in nasıl çalıştığını, HTTP 429'un neden önemli olduğunu ve dağıtık sistemlerde nasıl uygulandığını anlattık.

Bir Bot Tüm Sistemi Nasıl Çökertti?
API’n normal çalışıyor. CPU kullanımı düşük, veritabanı sağlıklı, her şey yolunda. Sonra bir bot saniyede binlerce istek göndermeye başlıyor.
İlk birkaç saniye sorun görünmüyor. Ardından CPU yükselmeye başlıyor, connection pool doluyor, loglar büyüyor. Gerçek kullanıcıların istekleri yavaşlıyor. Ve sonunda sistem cevap veremez hale geliyor.
Sunucu mu küçüktü? Kod mu kötüydü? Belki de sorun bunlardan hiçbiri değildi.
Trafik Her Zaman İyi Bir Şey Değildir
Çoğu geliştirici yüksek trafiği başarı göstergesi olarak görür. Ama kontrolsüz trafik ciddi bir problemdir. Botlar, yanlış yapılandırılmış istemciler, sonsuz döngüye giren uygulamalar veya kötü niyetli kullanıcılar sisteme çok kısa sürede büyük yük bindirebilir.
Şu koda bak:
setInterval(() => {
fetch("/api/products");
}, 10);
Bu kod tek bir istemciden saniyede yüzlerce istek üretir. Yanlışlıkla yazılmış olabilir, kasıtlı olabilir. Fark etmez — sonuç aynıdır.
Her İsteğin Bir Maliyeti Var
Bir API isteği bedava değildir. Her istek CPU kullanır, bellek tüketir, veritabanına erişebilir, cache sorgulayabilir, log oluşturabilir. Saniyede birkaç istek sorun değildir. Ama binlerce istek geldiğinde kaynaklar hızla tükenir, yanıt süreleri uzar, timeout’lar başlar ve gerçek kullanıcılar etkilenir.

Rate Limiting Nedir?
Rate Limiting belirli bir süre içinde yapılabilecek istek sayısını sınırlar. Bir kullanıcı bu sınırı aşarsa sistem ona şunu söyler:
HTTP/1.1 429 Too Many Requests
Bu bir hata değildir. Sistemin kendini koruduğunun işaretidir. Hiç cevap verememekten çok daha iyidir.
Basit Uygulama
Express’te express-rate-limit paketi ile hızlıca ekleyebilirsin:
import rateLimit from "express-rate-limit";
const limiter = rateLimit({
windowMs: 60 * 1000, // 1 dakika
max: 100, // maksimum 100 istek
message: { error: "Çok fazla istek gönderdiniz. Lütfen bekleyin." },
standardHeaders: true,
legacyHeaders: false,
});
app.use("/api", limiter);
Bu yapı her istemciyi dakikada 100 istek ile sınırlar.
Her Endpoint Aynı Olmamalı
Tüm endpoint’lere aynı limiti uygulamak yanlıştır. Login endpoint’i ile ürün listeleme endpoint’i aynı riski taşımaz.
const loginLimiter = rateLimit({
windowMs: 60 * 1000,
max: 5, // Dakikada 5 deneme
message: { error: "Çok fazla giriş denemesi." },
});
const searchLimiter = rateLimit({
windowMs: 60 * 1000,
max: 100,
});
const productsLimiter = rateLimit({
windowMs: 60 * 1000,
max: 500,
});
app.post("/api/auth/login", loginLimiter, loginHandler);
app.get("/api/search", searchLimiter, searchHandler);
app.get("/api/products", productsLimiter, productsHandler);
Login endpoint’i kaba kuvvet saldırılarının hedefidir. Dakikada 5 deneme bile çoğu senaryo için fazladır.
Dağıtık Sistemlerde Redis
Tek sunucuda memory tabanlı rate limiting yeterlidir. Ama birden fazla sunucu varsa her sunucu kendi sayacını tutar ve limit anlamsız hale gelir.
Server A → kullanıcı 100 istek yaptı, limit doldu
Server B → aynı kullanıcı, sayaç sıfır, 100 istek daha yapabilir
Server C → aynı kullanıcı, sayaç sıfır, 100 istek daha yapabilir
Çözüm Redis’te ortak bir sayaç tutmaktır:
import rateLimit from "express-rate-limit";
import RedisStore from "rate-limit-redis";
import { createClient } from "redis";
const redisClient = createClient({ url: process.env.REDIS_URL });
await redisClient.connect();
const limiter = rateLimit({
windowMs: 60 * 1000,
max: 100,
store: new RedisStore({
sendCommand: (...args: string[]) => redisClient.sendCommand(args),
}),
});
app.use("/api", limiter);
Artık tüm sunucular aynı sayacı kullanır. Kullanıcı hangi sunucuya istek atarsa atsın limit geçerlidir.

Özet
Tek bir istemci tüm sistem kaynaklarını tüketebilir — bot olması şart değil, hatalı bir istemci de yeterlidir.
Her API isteğinin CPU, bellek ve veritabanı maliyeti vardır.
Rate Limiting sistemi kontrolsüz trafiğe karşı korur.
Her endpoint farklı limite ihtiyaç duyar — login ile ürün listeleme aynı riski taşımaz.
Birden fazla sunucu varsa Redis ile merkezi sayaç kullanılmalıdır.
HTTP 429 bir hata değil, koruma mekanizmasıdır.
İlgili İçerikler