Architecture
A distributed transaction architecture diagram implementing the two-phase commit protocol with a transaction coordinator sending prepare and commit messages to participating services, with global abort on any vote failure. This template visualizes the classic 2PC protocol used when strong consistency is required across multiple services, showing the prepare, vote, and commit/abort phases. Important for understanding distributed consensus trade-offs in microservices architectures.
Full FlowZap Code
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"]
}
Why This 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.
How It Works
- 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 | Saga Distributed Transaction Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A saga orchestration architecture diagram with a central orchestrator coordinating multi-step distributed transactions across Order, Inventory, and Payment services, with a dedicated compensation chain for rollback on failure. This template models the orchestration-based saga pattern where a single coordinator manages the transaction lifecycle and triggers compensating actions when any step fails. Essential for architects implementing reliable distributed transactions without two-phase commit.
Architecture
A saga choreography architecture diagram where Order, Payment, and Inventory services coordinate through domain events without a central orchestrator, with each service publishing and subscribing to events that drive the transaction forward or trigger compensation. This template models the decentralized saga approach where services autonomously react to events, reducing single points of failure at the cost of increased complexity in tracking saga state. Best for teams preferring service autonomy over centralized control.
Architecture
A travel booking saga architecture diagram orchestrating flight, hotel, and car rental reservations as a single distributed transaction, with automatic compensation to cancel all bookings if any reservation step fails. This template models the classic saga use case where multiple independent services must either all succeed or all roll back, ensuring travelers never end up with partial bookings. Perfect for demonstrating saga patterns with a real-world business scenario.
Architecture
An order fulfillment saga architecture diagram with four sequential steps: customer verification, inventory reservation, payment authorization, and shipment creation, with a compensation chain that reverses completed steps on failure. This template models the end-to-end order lifecycle as a saga, showing how each service participates in the transaction and how compensating actions maintain data consistency. Ideal for e-commerce architects designing reliable order processing pipelines.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.