import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
// Configurat pentru Serverless / Edge
const ratelimit = new Ratelimit({
redis: Redis.fromEnv(),
limiter: Ratelimit.slidingWindow(10, "10 s"),
analytics: true,
});
export async function handleRequest(req: Request) {
const ip = req.headers.get("x-forwarded-for") ?? "127.0.0.1";
const { success, limit, remaining } = await ratelimit.limit(ip);
if (!success) {
return new Response("Prea multe cereri. Ia o pauză.", {
status: 429,
headers: {
"X-RateLimit-Limit": limit.toString(),
"X-RateLimit-Remaining": remaining.toString(),
},
});
}
return new Response("OK");
}Salutare. Am văzut destule API-uri îngenunchiate de un script de scraping scris prost de un junior, așa că hai să vorbim direct despre rate limiting. Nu de alta, dar văd des oameni care pun Redis pentru trei rute amărâte sau, invers, care încearcă să facă rate limiting complex direct în Nginx și își prind urechile în fișiere de configurare.
Am trecut prin toate variantele astea. La un proiect cu vreo 12k utilizatori activi pe zi, am început cu in-memory în Node, am trecut prin Nginx și am sfârșit cu o combinație de Redis și Upstash în funcție de serviciu. Uite cum văd eu lucrurile după ce am testat fiecare abordare pe banii clienților.
1. Nginx: Primul scut, dar cam orb
Dacă vrei să te aperi de atacuri brute-force sau de boți care îți bombardează rutele publice (cum ar fi /login sau /register), Nginx e sfânt. E extrem de rapid pentru că blochează traficul înainte să ajungă în aplicația ta Node, Go sau Python. Economisești resurse de procesare masiv.
La un magazin online, aveam atacuri constante de tip credential stuffing. Am pus direct limit_req_zone în Nginx și am redus încărcarea pe server cu 30% instant. Serverul de Node nici nu mai știa de acele request-uri.
Trade-off-ul: Nginx e orb la logica ta de business. Nu știe dacă userul e premium, dacă e logat sau ce ID are în baza de date. Poți filtra după IP, dar dacă 100 de oameni dintr-o corporație sau dintr-o rețea mobilă ies prin același IP public, riști să-i blochezi pe toți la grămadă.
2. Redis în regie proprie: Standardul de aur pentru aplicații monolit
Dacă ai nevoie de logică dinamică (de exemplu: utilizatorii free au voie 60 de request-uri pe minut, iar cei pro au 5000), Redis e răspunsul. Faci un middleware în aplicație care verifică token-ul din header și scrie în Redis folosind un algoritm de tip sliding window.
E rapid (latență de sub 1-2ms dacă Redis e în aceeași rețea cu aplicația) și îți permite să fii extrem de granular.
Trade-off-ul: Trebuie să administrezi tu instanța de Redis. Dacă Redis pică sau se umple memoria, ce faci? Dai bypass la limitare (fail-open) sau blochezi tot traficul (fail-closed)? În plus, la un trafic mare, conexiunile persistente către Redis pot deveni un blocaj.
3. Upstash Ratelimit: Salvarea pentru Serverless și Edge
Dacă rulezi pe Vercel (Next.js), Netlify sau Cloudflare Workers, nu prea poți folosi Redis-ul clasic din cauza limitărilor de conexiuni TCP din serverless. Aici intervine Upstash (care oferă Redis peste HTTP) și librăria lor dedicată de ratelimit.
Am implementat asta la un API de generat rapoarte PDF. Integrarea durează fix 5 minute și ai din start algoritmi complecși gata scriși (cum ar fi token bucket sau fixed window).
Trade-off-ul: Costul și latența. Dacă ai 10 milioane de request-uri pe lună, te va costa mult mai mult decât o instanță mică de Redis pe un VPS. În plus, fiind un apel HTTP extern, adaugi o latență de 15-30ms la fiecare request doar pentru verificarea limitei.
Concluzia mea
Regula mea de aur e simplă: protecția de bază împotriva boților o faci mereu în Nginx (pe IP). Limitarea fină, bazată pe abonamente sau drepturi de utilizator, o faci în Redis dacă ai infrastructură clasică, sau în Upstash/Edge dacă ești blocat pe serverless.
Voi cum gestionați cazurile în care clienții din aceeași rețea de birouri sunt blocați din cauza IP-ului comun?