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.
Code FlowZap complet
Client { # Client Application
n1: circle label:"Incoming Request"
n2: rectangle label:"Load Balancer"
n3: rectangle label:"Receive API Response"
n4: circle label:"End"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Gateway.n5.handle(top) [label="Route Request"]
n3.handle(right) -> n4.handle(left)
}
Gateway { # API Gateway
n5: rectangle label:"Authenticate JWT Token"
n6: diamond label:"Token Valid?"
n7: rectangle label:"Apply Rate Limiting"
n8: rectangle label:"Return 401 Unauthorized"
n9: diamond label:"Rate Limit OK?"
n10: rectangle label:"Route to Microservice"
n11: rectangle label:"Return 429 Throttled"
n12: rectangle label:"Aggregate Responses"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="Yes"]
n6.handle(bottom) -> n8.handle(top) [label="No"]
n7.handle(right) -> n9.handle(left)
n8.handle(top) -> Client.n3.handle(bottom) [label="401"]
n9.handle(right) -> n10.handle(left) [label="Yes"]
n9.handle(bottom) -> n11.handle(top) [label="No"]
n10.handle(bottom) -> Services.n13.handle(top) [label="Forward"]
n11.handle(top) -> Client.n3.handle(bottom) [label="429"]
n12.handle(top) -> Client.n3.handle(bottom) [label="Response"]
}
Services { # Microservices Cluster
n13: rectangle label:"Service Discovery Lookup"
n14: rectangle label:"User Service"
n15: rectangle label:"Order Service"
n16: rectangle label:"Inventory Service"
n17: rectangle label:"Compose Response"
n13.handle(right) -> n14.handle(left) [label="Users"]
n13.handle(bottom) -> n15.handle(top) [label="Orders"]
n14.handle(right) -> n17.handle(left)
n15.handle(right) -> n16.handle(left) [label="Check Stock"]
n16.handle(right) -> n17.handle(left)
n17.handle(top) -> Gateway.n12.handle(bottom) [label="Aggregated"]
}
Pourquoi ce workflow ?
Without a centralized API gateway, every microservice must independently handle authentication, rate limiting, and request routing—leading to duplicated logic, inconsistent security policies, and operational complexity. An API gateway provides a single entry point that enforces cross-cutting concerns before requests reach backend services, reducing attack surface and simplifying client integration.
Comment ça fonctionne
- Step 1: Client sends a request through the load balancer to the API Gateway.
- Step 2: The gateway validates the JWT token and checks authentication status.
- Step 3: Rate limiting is applied based on client identity and configured thresholds.
- Step 4: Authenticated and throttled requests are routed to the appropriate microservice via service discovery.
- Step 5: Backend services process the request and return responses through the gateway for aggregation.
- Step 6: The gateway composes the final response and returns it to the client.
Alternatives
Building authentication and rate limiting into each service leads to inconsistency and maintenance burden. Commercial API gateways like Kong or Apigee cost $10K-100K+/year. This FlowZap template helps teams visualize their gateway architecture before implementation.
Key Facts
| Template Name | Architecture de passerelle API pour microservices |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
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écouverte de services avec registre Consul ou Eureka, équilibrage de charge côté client, heartbeats de vérification de santé, et enregistrement/désenregistrement automatique des instances. Ce modèle visualise comment les microservices se localisent dynamiquement sans endpoints codés en dur, permettant une mise à l'échelle élastique et une infrastructure auto-réparatrice. Clé pour les équipes plateforme construisant une communication inter-services résiliente.
Architecture
Diagramme d'architecture Backend-for-Frontend avec des couches BFF séparées pour les clients web et mobile, chacune optimisant les réponses API pour sa plateforme spécifique tout en partageant des microservices backend communs. Ce modèle montre comment éviter les API universelles en adaptant l'agrégation des données et l'optimisation des charges utiles par type de client. Recommandé pour les équipes servant plusieurs plateformes frontend depuis un backend microservices partagé.
Architecture
Diagramme d'architecture de chorégraphie événementielle où les microservices se coordonnent par événements sans orchestrateur central, avec les services Commande, Paiement, Inventaire et Expédition réagissant aux événements de domaine les uns des autres. Ce modèle représente le pattern de coordination décentralisée où chaque service ne connaît que ses propres responsabilités et publie des événements pour que d'autres les consomment. Idéal pour les équipes favorisant l'autonomie des services plutôt que le contrôle centralisé des workflows.
Architecture
Diagramme d'architecture backend API serverless avec API Gateway, fonctions Lambda d'autorisation, fonctions de logique métier et services cloud managés incluant DynamoDB, S3, SQS et SNS pour un backend entièrement managé et auto-scalable. Ce modèle représente l'approche serverless-first où la gestion de l'infrastructure est entièrement éliminée, avec une tarification à l'invocation et une mise à l'échelle automatique jusqu'à zéro. Essentiel pour les startups et les équipes construisant des backends API événementiels économiques.
Architecture
Diagramme d'architecture saga par orchestration avec un orchestrateur central coordonnant des transactions distribuées multi-étapes à travers les services Commande, Inventaire et Paiement, avec une chaîne de compensation dédiée pour le rollback en cas d'échec. Ce modèle représente le pattern saga basé sur l'orchestration où un coordinateur unique gère le cycle de vie de la transaction et déclenche des actions compensatoires lorsqu'une étape échoue. Essentiel pour les architectes implémentant des transactions distribuées fiables sans commit en deux phases.