import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
// Configurare rate limiter cu sliding window
const ratelimit = new Ratelimit({
redis: Redis.fromEnv(),
limiter: Ratelimit.slidingWindow(10, "10 s"), // max 10 request-uri la fiecare 10 secunde
analytics: true,
});
export async function middleware(userId: string) {
const { success, limit, reset, remaining } = await ratelimit.limit(userId);
if (!success) {
return {
status: 429,
body: "Too Many Requests",
headers: {
"X-RateLimit-Limit": limit.toString(),
"X-RateLimit-Remaining": remaining.toString(),
"X-RateLimit-Reset": reset.toString()
}
};
}
return { status: 200, body: "OK" };
}Am văzut prea des startup-uri care pun Redis direct în infrastructură doar pentru a limita 3 endpoint-uri, sau oameni care se chinuie cu Nginx pentru logici complexe de business. Alegerea greșită a strategiei de rate limiting te costă fie bani aruncați pe infrastructură, fie latență aiurea pentru useri. În postarea asta îți arăt cum am împărțit eu deciziile astea de-a lungul anilor ca să nu-ți complici viața inutil.
Nginx: Scutul de la intrare (Layer 7 brut)
Nginx e sfânt când vrei să oprești atacurile brute și ieftine direct la graniță. Dacă ai rute publice precum /api/auth/login sau /api/register, nu vrei ca request-urile malițioase să ajungă deloc în Node.js sau Python ca să pornească hash-uirea de parole, care mănâncă CPU în draci.
La un proiect cu vreo 12k useri unici pe zi, ne trezeam periodic cu atacuri de tip credential stuffing. Am trântit o directivă clasică limit_req_zone în Nginx pe IP și am rezolvat problema instant. Nginx respinge request-ul cu statusul 429 sau 503 înainte ca aplicația mea să știe ce o lovește.
Trade-off-ul? E extrem de rigid. Dacă vrei să permiți unui user plătitor să facă mai multe request-uri decât unul pe planul free, ești blocat. Nginx nu știe în mod nativ cine e logat și cine nu în baza ta de date fără hack-uri complexe cu module Lua.
Redis self-hosted: Când logica de business dictează regulile
Aici intrăm în zona în care vrei flexibilitate maximă. Ai nevoie de rate limiting dinamic: userul X are dreptul la 100 de apeluri pe oră pe endpoint-ul de AI, userul Y are 10.000 pentru că plătește un abonament enterprise.
Am implementat asta într-un API de analytics. Foloseam algoritmul de token bucket implementat în Redis printr-un script Lua ca să ne asigurăm că operațiunea este atomică. Fiecare request verifica cheia userului în Redis, scădea un token și returna headers-urile standard de rate limit (X-RateLimit-Limit, X-RateLimit-Remaining).
Marele avantaj e viteza: Redis ține totul în RAM, deci latența adăugată e de sub 2-3 milisecunde dacă e în aceeași rețea cu API-ul tău. Dezavantajul? Trebuie să îl administrezi. Dacă Redis-ul pică sau se umple memoria din cauza unor chei fără TTL (Time To Live), îți poate bloca tot API-ul dacă nu ai scris un mecanism de fallback de tipul fail-open (să lași request-ul să treacă dacă baza de date de rate-limit nu răspunde).
Upstash Ratelimit: Serverless și zero bătăi de cap
Dacă rulezi pe Vercel, AWS Lambda sau Cloudflare Workers, conexiunile persistente către un Redis clasic sunt o durere de cap majoră din cauza limitărilor de connection pooling. Fiecare instanță serverless nouă deschide o conexiune și riști să blochezi baza de date rapid.
Aici strălucește Upstash. Ei oferă un SDK de rate limiting bazat pe HTTP, gândit special pentru medii serverless și edge computing. Am migrat recent un API de integrări pentru un client pe Upstash Ratelimit și am economisit cam 30% din timpul pe care l-am fi pierdut configurând și securizând un cluster de Redis propriu.
Totuși, ai un trade-off de latență. Chiar dacă au edge routing global, un request HTTP către Upstash adaugă între 15 și 40ms în funcție de regiune. Dacă API-ul tău trebuie să răspundă extrem de rapid, latența asta s-ar putea să te deranjeze.
Cum alegi până la urmă?
Regula mea simplă de selecție este:
- Folosește Nginx pentru protecție globală la nivel de IP (anti-DDoS brut, rute de login, pagini statice).
- Mergi pe Redis self-hosted / managed (AWS ElastiCache, direct în VPC-ul tău) dacă ai o aplicație monolită clasică cu trafic mare și reguli de business complexe.
- Alege Upstash dacă ești pe un stack serverless și nu vrei să îți bați capul cu DevOps-ul sau când ai nevoie de rate-limiting la nivel de Edge Middlewares.
Voi cum gestionați limitele astea? Ați pățit să vă pice Redis-ul în producție din cauza unei configurări greșite de TTL pe cheile de rate limit?