Architecture
Diagramme d'architecture de limiteur de débit implémentant l'algorithme token bucket avec compteurs distribués Redis, journaux de fenêtre glissante, identification par clé API, en-têtes de limite de débit et synchronisation multi-nœuds pour une application cohérente. Ce modèle montre comment protéger les API contre les abus et assurer une utilisation équitable entre les clients, avec des réponses HTTP 429 appropriées et des en-têtes Retry-After. Essentiel pour les équipes plateforme API construisant une infrastructure de limitation de débit de production.
Code FlowZap complet
Client { # Client
n1: circle label:"API Request"
n2: rectangle label:"Attach API Key"
n3: rectangle label:"Receive Response"
n4: circle label:"End"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> RateLimiter.n5.handle(top) [label="Request"]
n3.handle(right) -> n4.handle(left)
}
RateLimiter { # Rate Limiter (Token Bucket)
n5: rectangle label:"Extract Client Identity"
n6: rectangle label:"Lookup Rate Limit Config"
n7: rectangle label:"Check Token Bucket"
n8: diamond label:"Tokens Available?"
n9: rectangle label:"Consume Token"
n10: rectangle label:"Return 429 Too Many Requests"
n11: rectangle label:"Add Rate Limit Headers"
n12: rectangle label:"Forward to Backend"
n5.handle(right) -> n6.handle(left) [label="API Key / IP"]
n6.handle(right) -> n7.handle(left) [label="100 req/min"]
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left) [label="Yes"]
n8.handle(bottom) -> n10.handle(top) [label="No"]
n9.handle(right) -> n11.handle(left) [label="Decrement"]
n11.handle(right) -> n12.handle(left) [label="X-RateLimit-Remaining"]
n10.handle(right) -> n11.handle(left) [label="Retry-After"]
n10.handle(top) -> Client.n3.handle(bottom) [label="429"]
n12.handle(bottom) -> Backend.n13.handle(top) [label="Allowed"]
}
Backend { # Backend Service
n13: rectangle label:"Process Request"
n14: rectangle label:"Return Response"
n13.handle(right) -> n14.handle(left) [label="Execute"]
n14.handle(top) -> Client.n3.handle(bottom) [label="200"]
}
Store { # Rate Limit Store (Redis)
n15: rectangle label:"Redis Counter"
n16: rectangle label:"Sliding Window Log"
n17: rectangle label:"Distributed Sync"
n7.handle(bottom) -> Store.n15.handle(top) [label="INCR + EXPIRE"]
n15.handle(right) -> n16.handle(left) [label="Window Check"]
n16.handle(right) -> n17.handle(left) [label="Multi-Node"]
}
Pourquoi ce workflow ?
Without rate limiting, a single abusive client or a traffic spike can overwhelm your API, degrading performance for all users. A rate limiter enforces fair usage quotas per client, protecting backend services from overload while providing clear feedback through standard HTTP headers.
Comment ça fonctionne
- Step 1: The client identity is extracted from the API key or IP address.
- Step 2: The rate limit configuration is looked up for the identified client tier.
- Step 3: The token bucket in Redis is checked for available tokens.
- Step 4: If tokens are available, one is consumed and the request proceeds with rate limit headers.
- Step 5: If no tokens are available, a 429 Too Many Requests response is returned with a Retry-After header.
- Step 6: Distributed Redis synchronization ensures consistent rate limiting across multiple API gateway nodes.
Alternatives
Application-level rate limiting does not work across multiple instances. Cloud provider rate limiting (AWS API Gateway) is simpler but less customizable. This template shows the distributed token bucket implementation with Redis.
Key Facts
| Template Name | Architecture de limiteur de débit |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture CQRS de séparation lecture-écriture avec des chemins de commande et de requête dédiés, PostgreSQL pour les écritures, Redis ou Elasticsearch pour les lectures optimisées, et une couche de synchronisation événementielle avec surveillance du décalage. Ce modèle démontre le principe fondamental du CQRS de séparer les modèles de lecture et d'écriture pour mettre à l'échelle et optimiser chaque chemin indépendamment. Idéal pour les applications avec des ratios lecture/écriture asymétriques où la performance des requêtes est critique.
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.
Architecture
Diagramme d'architecture de migration Strangler Fig montrant le remplacement incrémental d'un monolithe legacy par de nouveaux microservices, utilisant une couche de routage pour répartir le trafic entre l'ancien et le nouveau système. Ce modèle représente la stratégie de migration éprouvée où les nouvelles fonctionnalités sont construites en microservices tandis que les endpoints legacy sont progressivement retirés. Essentiel pour les équipes modernisant des systèmes legacy sans réécriture risquée en big-bang.