Architecture
Diagramme d'architecture de composition d'API avec un service compositeur qui distribue des requêtes parallèles vers plusieurs microservices, collecte les réponses avec gestion de timeout et fusionne les résultats en une réponse unifiée unique avec support de repli partiel. Ce modèle représente le pattern de composition d'API utilisé lorsqu'une requête client unique nécessite des données de plusieurs services, évitant les appels directs de service à service. Utile pour les équipes construisant des couches d'agrégation dans les architectures microservices.
Code FlowZap complet
Client { # Client Application
n1: circle label:"Complex Query Request"
n2: rectangle label:"API Composer Service"
n3: rectangle label:"Receive Composed Response"
n4: circle label:"End"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Composer.n5.handle(top) [label="Compose"]
n3.handle(right) -> n4.handle(left)
}
Composer { # API Composition Layer
n5: rectangle label:"Parse Query Requirements"
n6: rectangle label:"Fan-Out Parallel Requests"
n7: rectangle label:"Collect Responses"
n8: diamond label:"All Responses Received?"
n9: rectangle label:"Merge and Transform"
n10: rectangle label:"Return Partial with Fallback"
n5.handle(right) -> n6.handle(left) [label="Decompose"]
n6.handle(bottom) -> Services.n11.handle(top) [label="GET /users"]
n6.handle(bottom) -> Services.n12.handle(top) [label="GET /orders"]
n6.handle(bottom) -> Services.n13.handle(top) [label="GET /products"]
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left) [label="Yes"]
n8.handle(bottom) -> n10.handle(top) [label="Timeout"]
n9.handle(top) -> Client.n3.handle(bottom) [label="Composed JSON"]
n10.handle(top) -> Client.n3.handle(bottom) [label="Partial JSON"]
}
Services { # Microservices
n11: rectangle label:"User Service"
n12: rectangle label:"Order Service"
n13: rectangle label:"Product Service"
n14: rectangle label:"User Response"
n15: rectangle label:"Order Response"
n16: rectangle label:"Product Response"
n11.handle(right) -> n14.handle(left) [label="Query"]
n12.handle(right) -> n15.handle(left) [label="Query"]
n13.handle(right) -> n16.handle(left) [label="Query"]
n14.handle(top) -> Composer.n7.handle(bottom) [label="User Data"]
n15.handle(top) -> Composer.n7.handle(bottom) [label="Order Data"]
n16.handle(top) -> Composer.n7.handle(bottom) [label="Product Data"]
}
Pourquoi ce workflow ?
When a single UI view requires data from multiple microservices, having the client make multiple API calls increases latency and complexity. The API composition pattern provides a server-side aggregation layer that fans out requests in parallel, collects responses, and returns a single unified result.
Comment ça fonctionne
- Step 1: The client sends a single query request to the API composer service.
- Step 2: The composer parses the query requirements and identifies which services to call.
- Step 3: Parallel requests are fanned out to User, Order, and Product services simultaneously.
- Step 4: Responses are collected with timeout handling for slow services.
- Step 5: If all responses arrive, they are merged into a single composed JSON response.
- Step 6: If some services timeout, a partial response with fallback data is returned.
Alternatives
GraphQL federation provides query-level composition without a custom aggregator. Client-side composition gives more control but increases latency. BFF pattern is similar but client-specific. This template shows the generic API composition approach.
Key Facts
| Template Name | Architecture du pattern de composition d'API |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
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 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 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 événementielle publish-subscribe avec broker de messages Kafka ou RabbitMQ, sérialisation d'événements, partitionnement de topics, livraison fan-out vers plusieurs consommateurs et gestion des erreurs via file de lettres mortes. Ce modèle représente le pattern fondamental de messagerie asynchrone où producteurs et consommateurs sont entièrement découplés via un broker de messages. Essentiel pour les architectes construisant des systèmes événementiels faiblement couplés et évolutifs.
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 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.