import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
// Configurare rate limiter pe Edge / Serverless
const ratelimit = new Ratelimit({
redis: Redis.fromEnv(),
limiter: Ratelimit.slidingWindow(10, "10 s"),
analytics: true,
prefix: "@upstash/ratelimit",
});
export async function handleRequest(req: Request) {
const userId = req.headers.get("x-user-id") ?? "ip_anonymous";
const { success, limit, remaining, reset } = await ratelimit.limit(userId);
if (!success) {
return new Response("Prea multe cereri. Încearcă mai târziu.", {
status: 429,
headers: {
"X-RateLimit-Limit": limit.toString(),
"X-RateLimit-Remaining": remaining.toString(),
"X-RateLimit-Reset": reset.toString(),
},
});
}
return new Response("OK", { status: 200 });
}Am văzut prea multe API-uri picate sau cu facturi uriașe pe Serverless doar pentru că cineva a uitat să pună un banal rate-limiter. Am trecut prin toate variantele în ultimii ani — de la un simplu Map în memorie care crăpa la restart, până la reguli complexe în Nginx și clustere de Redis. Hai să vezi exact când merită fiecare opțiune și unde îți furi singur căciula.
Nginx: Scutul brut de la intrare
Dacă vrei doar să oprești un bot să-ți facă spam pe /api/login sau să previi un DDoS simplu, Nginx e de nebătut. Folosește limit_req_zone și procesează totul direct în memorie, înainte ca request-ul să atingă Node.js, Go sau Python.
La un proiect unde aveam cam 50k request-uri pe minut, Nginx oprea 80% din traficul de tip scraping fără să consume mai mult de 200MB RAM pe VPS-ul principal.
Trade-off: Nginx e orb la contextul complex din aplicație. Poți filtra după IP sau după vreun header fix, dar nu poți pune ușor o limită de "100 de cereri pe lună pentru userii Free și 10.000 pentru Pro". Teoretic poți scrie scripturi de Lua prin OpenResty, dar mentenanța devine rapid un coșmar pe care nu vrei să-l lași moștenire echipei.
Self-hosted Redis: Când ai infrastructură clasică
Când ai nevoie de limite bazate pe user_id, role-uri sau pachete de abonament, Redis e standardul. Implementezi un algoritm de tip Sliding Window sau Token Bucket și verifici starea la fiecare cerere din backend.
La un SaaS cu 12k utilizatori activi zilnic, am folosit o instanță separată de Redis dedicată pentru asta. Aveam rate limiting diferențiat: ruta de /export-pdf lăsa doar 3 req/minut, în timp ce rutele de read aveau 300 req/minut per utilizator.
Trade-off: Trebuie să administrezi tu instanța. În 2021 am pățit-o urât: Redis-ul a rămas fără memorie din cauza unor chei fără TTL, iar middleware-ul nostru era configurat fail-closed (dacă Redis crapă, blochezi tot). Rezultatul? Am blocat tot API-ul timp de 20 de minute pentru utilizatorii legitimi. Învățătură de minte: folosește mereu fail-open pentru rate-limiting dacă serviciul tău nu e legat direct de procesat plăți.
Upstash Ratelimit: Când ești pe Serverless sau Edge
Dacă scrii cod pe Vercel, Cloudflare Workers sau AWS Lambda, conexiunile TCP clasice de Redis îți vor omorî performanța din cauza latenței de handshake la fiecare cold start. Aici intervine Upstash. Ei oferă un client de Redis peste HTTP și o librărie dedicată optimizată pentru mediul serverless.
Am migrat un API din Next.js pe Upstash și am economisit cam 40% din timpul de executie al middleware-ului, pentru că librăria face ephemeral caching în memoria funcției (păstrează starea local pentru câteva secunde și scade numărul de apeluri externe).
Trade-off: Prețul la volum mare. Cât timp ai trafic mic sau mediu, tier-ul lor free sau câțiva dolari pe lună e pont. Dar dacă ai un flux constant de 2.000 req/secundă, numărul de apeluri HTTP către Upstash crește exponențial și te trezești cu o factură mai mare decât serverul pe care ar fi rulat un Redis dedicat.
Cum alegi până la urmă?
Regula mea e destul de simplă:
- Pune Nginx la margine pentru protecție brutală după IP împotriva atacurilor de tip brute-force.
- Folosește Upstash dacă ești pe Next.js/Vercel/Edge și nu vrei bătai de cap cu devops-ul.
- Mergi pe Redis self-hosted dacă ai aplicații monolit sau microservicii pe Docker/K8s și volum mare de date.
Voi cum ați tratat problema asta? Mergeți pe fail-open sau preferați să blocați tot când pica serviciul de rate-limit?