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);

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.