Le rate limiting est un mécanisme de protection qui limite le nombre de requêtes qu'un client peut effectuer dans un intervalle de temps donné. Du côté fournisseur, il protège vos serveurs contre la surcharge. Du côté consommateur, il vous oblige à gérer intelligemment vos appels aux APIs tierces.
Une mauvaise gestion du rate limiting peut casser vos intégrations : erreurs 429 en cascade, dégradation de l'expérience utilisateur, voire blocage temporaire de votre accès à une API critique.
Ce guide couvre les deux perspectives : implémenter le rate limiting pour protéger vos API, et le gérer intelligemment quand vous consommez des APIs tierces.
Concepts du Rate Limiting
Comprenez les mécanismes fondamentaux :
- Limite (Limit) : nombre maximum de requêtes autorisées dans une fenêtre de temps (ex: 100 req/min, 1000 req/heure).
- Fenêtre (Window) : période sur laquelle la limite s'applique. Peut être fixe (par minute calendaire) ou glissante (les 60 dernières secondes).
- Identifiant : ce qui identifie le client : IP, API key, user ID, tenant. Détermine la granularité des limites.
- Quota : limite sur une période plus longue (jour, mois), souvent liée au plan de tarification.
Algorithmes de Rate Limiting
Différentes approches avec leurs avantages :
- Fixed Window : limite par intervalle fixe (ex: par minute calendaire). Simple mais permet des pics en chevauchant deux fenêtres.
- Sliding Window : fenêtre glissante qui lisse les limites. Plus précis mais nécessite de stocker plus d'état.
- Token Bucket : accumulation de "tokens" à rythme constant. Permet des bursts tant que des tokens sont disponibles. Flexible et populaire.
- Leaky Bucket : file d'attente avec traitement à rythme fixe. Lisse parfaitement le trafic mais peut ajouter de la latence.
Surveiller le Rate Limiting
Métriques clés pour anticiper les problèmes :
- Utilisation du quota : quel pourcentage de votre limite utilisez-vous ? Alertez avant d'atteindre 80% pour avoir le temps de réagir.
- Erreurs 429 : nombre de requêtes rejetées. Doit rester proche de zéro pour les APIs que vous consommez.
- Temps avant reset : via le header X-RateLimit-Reset. Permet de programmer intelligemment les retries.
- Répartition dans le temps : évitez les pics en répartissant vos appels. Un volume stable est plus facile à gérer qu'un burst.
Headers de Rate Limiting
Les headers standards pour gérer les limites :
HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 67
X-RateLimit-Reset: 1640995200
Retry-After: 42
# Sur erreur 429:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1640995260
Parsez ces headers dans vos clients pour adapter votre comportement : ralentir quand Remaining baisse, attendre Retry-After après un 429.
Gérer les Limites Côté Client
Stratégies pour respecter les limites des APIs :
- Lire les headers : surveillez X-RateLimit-Remaining à chaque réponse. Ralentissez proactivement quand il baisse.
- Exponential backoff : après un 429, attendez de plus en plus longtemps entre chaque retry (1s, 2s, 4s...).
- File d'attente : implémentez une queue qui régule le débit d'envoi pour ne jamais dépasser la limite.
- Caching agressif : cachez les réponses pour éviter des appels redondants. Chaque appel économisé préserve le quota.
Bonnes Pratiques
Recommandations pour une gestion saine :
- Documentez vos limites : rendez les limites visibles dans votre documentation et vos dashboards. L'équipe doit savoir où on en est.
- Alertes proactives : alertez à 70-80% d'utilisation, pas à 100%. Le temps de réagir avant le blocage est crucial.
- Plan de contingence : que faire si vous atteignez la limite ? Fallback, cache, file d'attente, upgrade de plan ?
- Testez en staging : simulez des conditions de rate limiting en staging pour valider le comportement de votre application.
Checklist Rate Limiting
- Limites des APIs consommées documentées
- Headers de rate limiting parsés dans les clients
- Exponential backoff implémenté sur les 429
- Alertes sur utilisation du quota > 70%
- Plan de contingence en cas de blocage
Questions Fréquentes
Rate limit par IP ou par API key ?
Par API key est plus précis et équitable. Par IP peut pénaliser des clients légitimes derrière un NAT. Idéalement, combinez les deux avec des limites différentes.
Comment choisir les limites ?
Analysez l'usage réel, identifiez les patterns normaux et les abus. Fixez les limites au-dessus de l'usage normal mais en dessous de ce que vos serveurs peuvent supporter.
Faut-il retourner 429 ou 503 ?
429 (Too Many Requests) est spécifique au rate limiting et inclut Retry-After. 503 indique une indisponibilité temporaire plus générale.
Comment gérer les bursts légitimes ?
Token bucket permet des bursts dans la limite du bucket. Alternativement, offrez des limites plus élevées aux clients premium ou sur demande.
Peut-on monitorer le rate limiting des APIs tierces ?
MoniTao peut alerter sur les erreurs 429. Pour un suivi plus fin du quota, parsez les headers dans votre code et exposez les métriques.
Comment tester le rate limiting ?
Envoyez des requêtes en boucle jusqu'à recevoir des 429. Vérifiez que le backoff fonctionne et que l'application se rétablit après le reset.
Conclusion
Le rate limiting protège les API contre les abus et garantit une qualité de service équitable. Que vous l'implémentiez ou que vous le subissiez, une gestion intelligente est essentielle.
MoniTao vous alerte sur les erreurs 429 et vous aide à détecter les problèmes de quota avant qu'ils n'impactent vos utilisateurs. Combinez monitoring et bonne implémentation client pour des intégrations robustes.
Prêt à dormir sur vos deux oreilles ?
Commencez gratuitement, sans carte bancaire.