Rate limiter et circuit breaker dans un API Gateway : quel coût en latence ?
Un rate limiter mal placé peut ajouter des dizaines de millisecondes à chaque requête. Bien conçu, il en ajoute moins d'une. Le gateway Rust d'Aurabase (aura-gateway) implémente les deux mécanismes — rate limiting distribué et circuit breaker — au cœur de sa pile de middlewares. Voici ce que dit la littérature technique, et ce que le code Aurabase fait précisément.
Un rate limiter distribué correctement implémenté (comptage atomique, cache local en repli) ajoute typiquement moins d'une milliseconde par requête selon plusieurs sources spécialisées. Le gateway Aurabase suit exactement ce patron : la crate governor pour l'anti-DoS local, un script Lua Redis atomique pour le comptage distribué entre instances, un cache moka en repli si Redis est indisponible. Le circuit breaker, lui, réduit la latence perçue en cas de panne plutôt que d'en ajouter — il court-circuite l'attente d'un timeout complet. Aucun chiffre de latence Aurabase n'est publié à ce jour : voici pourquoi, et comment le mécanisme fonctionne réellement.
Anti-DoS et anti-panne en cascade, deux problèmes distincts
Le rate limiter protège votre backend contre un volume de trafic excessif, légitime ou non — il répond à la question « cet appelant a-t-il le droit d'envoyer cette requête maintenant ? ». Le circuit breaker protège votre backend contre un service en aval déjà en panne — il répond à « ce service a-t-il déjà montré qu'il ne répond plus, faut-il même essayer ? ». Les confondre conduit à sous-dimensionner l'un ou l'autre.
Sur le gateway Aurabase, les deux vivent dans la même pile de middlewares mais à des étages différents : le rate limiting par IP s'exécute avant l'authentification (anti-DoS pur, aucune requête SQL de facturation émise pour du trafic non authentifié), tandis que le circuit breaker protège les appels sortants vers des services internes ou des fournisseurs LLM.
Le coût dépend entièrement de l'implémentation, pas du principe
Selon Tyk et les guides de l'écosystème APISIX, un comptage distribué bien conçu sur Redis (opérations atomiques, script Lua, TTL natif) ajoute typiquement 1 à 3 ms de latence, avec un impact p99 inférieur à la milliseconde dans les cas les mieux optimisés. À l'inverse, Zuplo documente qu'un rate limiter centralisé mal placé peut ajouter des dizaines de millisecondes à chaque requête — cet écart se répercute directement sur votre p99.
Le gateway Aurabase utilise la crate governor (algorithme à seau de jetons) comme limiteur local de repli, doublé d'un comptage distribué via Redis pour partager l'état entre plusieurs instances du gateway. Le comptage distribué passe par un script Lua exécuté atomiquement côté Redis (INCRBY + EXPIRE en une seule opération réseau), pas par un aller-retour lire-puis-écrire qui introduirait une fenêtre de concurrence.
Si Redis devient indisponible, le gateway bascule automatiquement sur le limiteur local governor, avec un cache moka (max 1 000 000 entrées, expiration à 300 secondes d'inactivité) pour éviter de recréer un limiteur à chaque requête. Ce repli est observable : chaque bascule incrémente un compteur Prometheus dédié, pour que l'équipe sache quand la limite effective redevient N instances × limite (dégradation d'isolation inter-instances silencieuse sinon).
Le circuit breaker : trois états, une fenêtre glissante
Le circuit breaker d'Aurabase (aura_core::circuit_breaker, partagé entre le gateway et aura-ai pour le fallback entre fournisseurs LLM) suit trois états classiques — Closed, Open, HalfOpen — avec un décompte d'échecs sur une fenêtre glissante temporelle plutôt qu'un compteur qui ne se réinitialise jamais.
Un détail d'implémentation qui compte en production : le passage en HalfOpen n'autorise qu'une seule requête sonde à la fois (anti thundering-herd) — sans cette garde, toutes les requêtes en attente se rueraient simultanément sur le service qui vient de rouvrir, recréant immédiatement la panne qu'on cherchait à éviter.
Où ces middlewares s'exécutent dans le gateway
La pile de middlewares du gateway Aurabase suit un ordre précis, vérifié dans le code : identifiant de requête → journal d'accès → rate limiting par IP → authentification → rate limiting par acteur/quota → circuit breaker → proxy vers le service cible. Chaque étage rejette le trafic indésirable le plus tôt possible, avant d'engager un coût de traitement plus élevé en aval.
Lire l'article complet : data plane vs management plane dans le gateway AurabasePourquoi aucun chiffre Aurabase n'est publié ici
L'implémentation est vérifiée ligne par ligne dans le code source du gateway. Mais aucun protocole de mesure reproductible n'a encore été exécuté et publié sur cette infrastructure précise — publier un chiffre non mesuré reviendrait à répéter l'erreur des chiffres marketing non sourcés que nous refusons de reproduire. Voir notre méthodologie de benchmark complète pour ce que nous exigeons avant de publier un chiffre de performance.
Comment le rate limiting fonctionne réellement dans aura-gateway