import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
// Instanțiem ratelimiter-ul cu algoritm Sliding Window
const ratelimit = new Ratelimit({
redis: Redis.fromEnv(),
limiter: Ratelimit.slidingWindow(10, "10 s"),
analytics: true,
prefix: "@upstash/ratelimit",
});
export async function handleApiRequest(userId: string) {
// Verificăm cota per userId, nu per IP
const { success, limit, remaining, reset } = await ratelimit.limit(userId);
if (!success) {
return new Response("Too Many Requests", {
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 pățit-o acum vreo doi ani pe o aplicație SaaS cu vreo 12k useri activi. Un scraper agresiv ne-a făcut 40.000 de request-uri într-un interval de 5 minute pe un endpoint necache-uit de căutare, iar baza de date a intrat direct în comă. Atunci am înțeles că rate limiting-ul nu e opțional, ci e o cerință de bază pentru supraviețuirea producției.
Nu există o singură soluție universală. Alegerea depinde de unde se află aplicația ta, ce arhitectură ai și cât timp vrei să pierzi cu mentenanța.
Nginx: Scutul direct la intrare
Dacă ai un VPS clasic, un monolit în Docker sau un reverse proxy gestionat de tine, Nginx e prima linie de apărare. Se mișcă incredibil de rapid pentru că oprește traficul înainte ca request-ul să ajungă măcar la procesul tău de Node.js, Go sau Python.
Merge perfect când vrei să blochezi atacuri brute-force sau scannere pe IP (de exemplu pe /api/login sau /api/search). Configurezi o zonă de memorie cu limit_req_zone și ai rezolvat problema.
Trade-off sincer: Nginx știe doar ce vede în HTTP header / IP. Dacă vrei limitări dinamice bazate naiv pe pachetul utilizatorului (ex: userul Freemium are 100 req/oră, iar cel PRO are 10.000 req/oră pe baza unui token JWT decodat), Nginx devine rapid un coșmar de configurat. De asemenea, într-un cluster cu mai multe instanțe de Nginx, starea nu se împarte ușor fără module complexe.
Redis custom: Control total în backend
Când ai nevoie de logică de business — adică limite diferite per tenant, per API key sau per rol —, soluția clasică este un Redis separat conectat la backend-ul tău. Am folosit abordarea asta la un sistem de procesare de fișiere unde trebuia să scădem din cota lunară a fiecărui client.
Implementezi un algoritm de tip Sliding Window Log sau Token Bucket (de preferat prin scripturi Lua rulat direct pe Redis ca să fie operații atomice) și verifici limita în middleware-ul aplicației.
Trade-off sincer: Adaugi o latență suplimentară (network round-trip) la fiecare request primit. Dacă baza ta de Redis pică sau are spike-uri de latență, pică tot API-ul tău (dacă nu ai un fallback de tip fail-open). În plus, dacă ai 50 de microservicii, toate vor aglomera conexiunile către Redis.
Upstash Ratelimit: Opțiunea serverless
Dacă ești pe Vercel, Cloudflare Workers, Next.js Edge sau AWS Lambda, conexiunile TCP persistente către un Redis clasic sunt un calvar (din cauza problemelor de connection pooling). Aici intervine Upstash cu SDK-ul lor dedicat @upstash/ratelimit peste HTTP.
Procesul e extrem de simplu: au un algoritm hibrid de sliding window care poate face ephemeral cache în memoria locală a funcției serverless pentru câteva secunde, scăzând masiv numărul de apeluri la baza de date.
Trade-off sincer: E un serviciu extern (vendor lock-in ușor) și te costă per request dacă sari de tier-ul gratuit. La un volum masiv de 50-100 milioane de request-uri pe lună, o să te coste sensibil mai mult decât dacă îți administrezi singur o instanță de Redis pe Hetzner.
Ce alegi până la urmă?
Strategia mea preferată pe proiectele medii și mari este hibridă: pun un rate limit brut pe IP în Nginx/Cloudflare (ex: max 200 req/min per IP) ca să opresc potopul de boti, și folosesc Redis sau Upstash în backend doar pentru endpoints critice unde aplic reguli de business complexe per user.
Voi cum gestionați limitele în aplicațiile voastre? Mergeți pe soluție la nivel de infrastructură sau rezolvați totul din codul de backend?