Que fait Limitation de Débit ?
Règles
- Utiliser le bucket à jetons pour les points de terminaison d'API, la fenêtre glissante pour les routes d'authentification/connexion
- Identifier les appelants d'abord par clé API, puis par IP en fallback — jamais uniquement par IP pour les routes authentifiées
- Retourner
429 Too Many Requests avec l'en-tête Retry-After (secondes) et l'en-tête X-RateLimit-Remaining
- Stocker les compteurs dans Redis (ou Upstash pour le serverless) — jamais en mémoire pour les déploiements multi-instances
- Définir des valeurs par défaut raisonnables : 100 req/min pour l'API générale, 5 req/min pour l'authentification, 1000 req/min pour les lectures
- Utiliser
@upstash/ratelimit pour le serverless — il gère l'atomicité Redis et la fenêtre glissante nativement
- Implémenter la limitation de débit en tant que middleware — appliquer globalement, remplacer par route avec des limites plus strictes
- Pour Next.js : limiter le débit dans middleware.ts ou les gestionnaires de route d'API, pas dans les composants React
- Séparer les limites par niveau : gratuit, pro, entreprise — stocker le niveau dans JWT ou via une recherche en base de données
- Journaliser les hits de limitation de débit avec l'identité de l'appelant — détecter les schémas d'abus tôt
Modèles
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
const ratelimit = new Ratelimit({
redis: Redis.fromEnv(),
limiter: Ratelimit.slidingWindow(10, "10 s"),
analytics: true,
});
const { success, limit, remaining, reset } = await ratelimit.limit(identifier);
À Éviter
- Limitation de débit en mémoire dans des configurations serverless ou multi-instances — l'état est perdu entre les invocations
- Limiter le débit uniquement au niveau applicatif — ajouter aussi des limites CDN/Edge (Cloudflare, Vercel)
- Bloquer les utilisateurs légitimes avec des limites trop agressives — commencer permissif, resserrer en fonction des données
- Oublier de limiter le débit des webhooks et des soumissions de formulaires publics