import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
// Sliding window: 10 request-uri la fiecare 10 secunde per user
const ratelimit = new Ratelimit({
redis: Redis.fromEnv(),
limiter: Ratelimit.slidingWindow(10, "10 s"),
analytics: true,
});
export async function checkRateLimit(userId: string) {
const { success, limit, remaining, reset } = await ratelimit.limit(`user:${userId}`);
if (!success) {
return {
blocked: true,
status: 429,
headers: {
"X-RateLimit-Limit": limit.toString(),
"X-RateLimit-Remaining": remaining.toString(),
"X-RateLimit-Reset": reset.toString(),
},
};
}
return { blocked: false };
}Am picat examenul de rate limiting acum vreo 6 ani, când un bot destul de prost ne-a generat 500.000 de request-uri într-un weekend și ne-a crăpat baza de date. De atunci am trecut prin toate variantele: de la simple variabile păstrate în memorie în Node.js, până la clustere de Redis și soluții serverless.
Dacă aplici aceeași soluție peste tot, fie arunci bani pe fereastră, fie îți pică infrastructura la primul spike serios. Hai să le luăm pe rând.
1. Nginx: Primul scut, înainte să atingă aplicația
Dacă vrei doar să oprești scraping-ul agresiv sau atacurile brute-force pe /login, Nginx e sfânt. Se execută direct la nivel de reverse proxy, consumă resurse infime și blochează traficul înainte ca procesul tău de Node.js, Go sau Python să aloce vreun megabait de memorie.
L-am folosit cu succes pe un server cu 8k utilizatori activi zilnic, unde aveam atacuri constante pe endpoint-ul de autentificare. Am setat o zonă de limit_req cu rate=5r/s și am scăpat de 90% din zgomot fără să ating vreun rând de cod din aplicație.
Trade-off: Nginx nu știe cine e utilizatorul tău din spatele unui JWT sau token complex fără artificii urâte. Limitează doar după IP sau header-e HTTP simple. În plus, dacă ai 5 IP-uri de NAT de la o corporație mare, îi blochezi pe toți la pachet.
2. In-memory: Ieftin și rapid, dar limitat
Varianta in-memory (folosind un Map, LRU cache sau pachete gen express-rate-limit) e excelentă dacă rulezi un singur container sau o instanță monolită și nu ai buget de infra. Verificarea durează sub 0.1ms pentru că ai zero latență de rețea.
Am folosit pattern-ul ăsta la micro-servicii interne. Funcționează perfect până în momentul în care faci scale-out.
Trade-off: Dacă ai 4 pod-uri de Kubernetes, fiecare va avea propriul lui contor. Un user poate face de 4 ori mai multe request-uri permise dacă nimerește pod-uri diferite prin Round-Robin. Mai mult, la fiecare deploy sau restart de container, toate limitele se resetează la zero.
3. Redis și Upstash: Când ai nevoie de stare distribuită
Dacă ai aplicație serverless (Vercel, AWS Lambda) sau un cluster de microservicii scalat orizontal, Redis e singura opțiune serioasă. Aici poți folosi algoritmi preciși ca Sliding Window Log sau Token Bucket, bazat pe userId, nu doar pe IP.
Upstash e genial aici pentru că folosește HTTP/REST în loc de conexiuni TCP persistente, fiind ideal pentru medii edge/serverless unde conexiunile clasice de Redis mor repede sau epuizează socket-urile.
Am salvat recent vreun 30% din costurile de infrastructură la un client mutând logica complexă de rate-limiting pe un abonament mic de Upstash, cu algoritmul de Sliding Window.
Trade-off: Adaugi un hop de rețea. Fiecare request trebuie să facă un call către Redis (chiar dacă e 2-5ms, se adună). Dacă Redis pică și nu ai un fallback bine scris (fail-open), îți blochezi tot API-ul.
Ce alegi până la urmă?
Regula mea e simplă:
- Blochează botii și traficul anonim la nivel de Nginx (după IP).
- Folosește Redis / Upstash pentru limite pe utilizator autentificat, abonamente tiered (Free vs Pro) sau medii serverless.
- Rămâi la In-Memory doar dacă ești pe o singură instanță și nu te deranjează pierderea stării la restart.
Voi ce folosiți în producție când aveți spike-uri neașteptate? Mergeți pe Nginx sau lăsați totul în spatele unui API Gateway gen Cloudflare?