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.
Code FlowZap complet
Gateway { # API Gateway
n1: circle label:"Client Request"
n2: rectangle label:"Route to Service"
n3: rectangle label:"Aggregate Responses"
n4: circle label:"Return to Client"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> UserService.n5.handle(top) [label="User Data"]
n2.handle(bottom) -> OrderService.n9.handle(top) [label="Order Data"]
n3.handle(right) -> n4.handle(left)
}
UserService { # User Service
n5: rectangle label:"Handle User Request"
n6: rectangle label:"Query User DB"
n7: rectangle label:"User PostgreSQL"
n8: rectangle label:"Return User Data"
n5.handle(right) -> n6.handle(left)
n6.handle(right) -> n7.handle(left) [label="SELECT"]
n7.handle(right) -> n8.handle(left) [label="Result"]
n8.handle(top) -> Gateway.n3.handle(bottom) [label="User JSON"]
}
OrderService { # Order Service
n9: rectangle label:"Handle Order Request"
n10: rectangle label:"Query Order DB"
n11: rectangle label:"Order MongoDB"
n12: rectangle label:"Return Order Data"
n9.handle(right) -> n10.handle(left)
n10.handle(right) -> n11.handle(left) [label="find()"]
n11.handle(right) -> n12.handle(left) [label="Documents"]
n12.handle(top) -> Gateway.n3.handle(bottom) [label="Order JSON"]
}
EventBus { # Event Bus (Kafka)
n13: rectangle label:"Publish Domain Event"
n14: rectangle label:"Event Topic"
n15: rectangle label:"Consume Event"
n16: rectangle label:"Sync Read Model"
n13.handle(right) -> n14.handle(left) [label="UserUpdated"]
n14.handle(right) -> n15.handle(left) [label="Subscribe"]
n15.handle(right) -> n16.handle(left)
n16.handle(top) -> OrderService.n11.handle(bottom) [label="Update Denormalized"]
n13.handle(top) -> UserService.n8.handle(bottom) [label="After Write"]
}
Pourquoi ce workflow ?
Sharing a single database across microservices creates tight coupling, schema change conflicts, and performance bottlenecks that defeat the purpose of microservices. The database-per-service pattern ensures each service owns its data, enabling independent deployment, technology-appropriate storage choices, and fault isolation.
Comment ça fonctionne
- Step 1: Each microservice owns a dedicated database optimized for its access patterns.
- Step 2: The User Service uses PostgreSQL for relational data; the Order Service uses MongoDB for document storage.
- Step 3: Cross-service data needs are fulfilled through event-driven synchronization via Kafka.
- Step 4: When a user updates their profile, a UserUpdated event is published to the event bus.
- Step 5: The Order Service consumes the event and updates its denormalized user data.
- Step 6: The API Gateway aggregates responses from multiple services for client queries.
Alternatives
Shared databases are simpler but create deployment coupling and single points of failure. Database-per-service with synchronous API calls creates latency chains. This template shows the event-driven approach that balances autonomy with data consistency.
Key Facts
| Template Name | Architecture base de données par service pour microservices |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
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 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 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 CQRS combinant des API de commande et de requête séparées avec un bus d'événements pour la synchronisation asynchrone du modèle de lecture, incluant des projecteurs qui construisent des vues dénormalisées à partir des événements de domaine. Ce modèle démontre la pile complète CQRS+ES où les écritures passent par la validation du domaine et les lectures sont servies depuis des vues matérialisées optimisées. Idéal pour les systèmes à haut débit où les charges de lecture et d'écriture ont des exigences de mise à l'échelle fondamentalement différentes.
Architecture
Diagramme d'architecture de pipeline de streaming temps réel avec capteurs IoT, logs applicatifs et données de parcours utilisateur transitant par Kafka vers Apache Flink pour l'agrégation par fenêtre, la détection d'anomalies et la sortie multi-destinations vers des lacs de données et des tableaux de bord. Ce modèle visualise le traitement de flux de bout en bout, de l'ingestion à la transformation, au stockage et à l'alerte. Essentiel pour les ingénieurs data construisant des plateformes d'analyse et de surveillance en temps réel.