Architecture
Diagramme d'architecture de transaction distribuée implémentant le protocole de commit en deux phases avec un coordinateur de transaction envoyant des messages de préparation et de commit aux services participants, avec un abandon global en cas d'échec de vote. Ce modèle visualise le protocole 2PC classique utilisé lorsqu'une cohérence forte est requise entre plusieurs services, montrant les phases de préparation, vote et commit/abandon. Important pour comprendre les compromis de consensus distribué dans les architectures microservices.
Code FlowZap complet
Coordinator { # Transaction Coordinator
n1: circle label:"Begin Distributed Transaction"
n2: rectangle label:"Assign Transaction ID"
n3: rectangle label:"Send Prepare to All"
n4: rectangle label:"Collect Votes"
n5: diamond label:"All Voted Commit?"
n6: rectangle label:"Send Global Commit"
n7: rectangle label:"Send Global Abort"
n8: circle label:"Transaction Complete"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="TxID"]
n3.handle(bottom) -> ServiceA.n9.handle(top) [label="Prepare"]
n3.handle(bottom) -> ServiceB.n12.handle(top) [label="Prepare"]
n3.handle(bottom) -> ServiceC.n15.handle(top) [label="Prepare"]
n4.handle(right) -> n5.handle(left)
n5.handle(right) -> n6.handle(left) [label="Yes"]
n5.handle(bottom) -> n7.handle(top) [label="No"]
n6.handle(right) -> n8.handle(left)
n7.handle(right) -> n8.handle(left) [label="Rolled Back"]
n6.handle(bottom) -> ServiceA.n11.handle(top) [label="Commit"]
n6.handle(bottom) -> ServiceB.n14.handle(top) [label="Commit"]
n6.handle(bottom) -> ServiceC.n17.handle(top) [label="Commit"]
}
ServiceA { # Booking Service
n9: rectangle label:"Lock Resources"
n10: rectangle label:"Vote Commit"
n11: rectangle label:"Apply Changes"
n9.handle(right) -> n10.handle(left) [label="Prepared"]
n10.handle(top) -> Coordinator.n4.handle(bottom) [label="Vote"]
}
ServiceB { # Payment Service
n12: rectangle label:"Hold Funds"
n13: rectangle label:"Vote Commit"
n14: rectangle label:"Capture Payment"
n12.handle(right) -> n13.handle(left) [label="Prepared"]
n13.handle(top) -> Coordinator.n4.handle(bottom) [label="Vote"]
}
ServiceC { # Notification Service
n15: rectangle label:"Queue Notification"
n16: rectangle label:"Vote Commit"
n17: rectangle label:"Send Notification"
n15.handle(right) -> n16.handle(left) [label="Prepared"]
n16.handle(top) -> Coordinator.n4.handle(bottom) [label="Vote"]
}
Pourquoi ce workflow ?
When strong consistency is absolutely required across multiple services (e.g., financial transactions), eventual consistency is not acceptable. The two-phase commit protocol ensures all participants either commit or abort together, providing ACID-like guarantees across distributed services at the cost of availability during the prepare phase.
Comment ça fonctionne
- Step 1: The transaction coordinator assigns a unique transaction ID and sends prepare messages to all participants.
- Step 2: Each participant locks its resources and votes commit or abort.
- Step 3: The coordinator collects all votes and makes a global decision.
- Step 4: If all participants voted commit, a global commit message is sent.
- Step 5: If any participant voted abort, a global abort message is sent to all.
- Step 6: Participants apply or rollback changes based on the global decision.
Alternatives
Saga patterns provide better availability but only eventual consistency. Consensus protocols like Raft/Paxos are used for state machine replication. This template shows the classic 2PC protocol for understanding distributed consensus trade-offs.
Key Facts
| Template Name | Architecture de transaction distribuée Saga |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
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.
Architecture
Diagramme d'architecture saga par chorégraphie où les services Commande, Paiement et Inventaire se coordonnent par événements de domaine sans orchestrateur central, chaque service publiant et s'abonnant à des événements qui font avancer la transaction ou déclenchent la compensation. Ce modèle représente l'approche saga décentralisée où les services réagissent de manière autonome aux événements, réduisant les points de défaillance uniques au prix d'une complexité accrue dans le suivi de l'état de la saga. Idéal pour les équipes préférant l'autonomie des services au contrôle centralisé.
Architecture
Diagramme d'architecture saga de réservation de voyage orchestrant les réservations de vol, d'hôtel et de location de voiture comme une seule transaction distribuée, avec compensation automatique pour annuler toutes les réservations si une étape échoue. Ce modèle représente le cas d'usage classique de saga où plusieurs services indépendants doivent tous réussir ou tous annuler, garantissant que les voyageurs ne se retrouvent jamais avec des réservations partielles. Parfait pour démontrer les patterns saga avec un scénario métier réel.
Architecture
Diagramme d'architecture saga d'exécution de commande avec quatre étapes séquentielles : vérification du client, réservation d'inventaire, autorisation de paiement et création d'expédition, avec une chaîne de compensation qui inverse les étapes complétées en cas d'échec. Ce modèle représente le cycle de vie complet de la commande sous forme de saga, montrant comment chaque service participe à la transaction et comment les actions compensatoires maintiennent la cohérence des données. Idéal pour les architectes e-commerce concevant des pipelines de traitement de commandes fiables.
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é.