I really enjoyed rereading Chapter 12 of Software Architecture: The Hard Parts by Neal Ford, Mark Richards, Pramod S. and Zhamak Dehghani (O’Reilly 2022) this May break🌞. That chapter is about Transactional Sagas, and I couldn’t resist turning it into a short post 🙂. The authors take the forces of communication, consistency, and coordination and turn them into eight saga patterns with different trade-offs, all neatly captured in a saga comparison matrix and presented with funny story-style names. That comparison matrix is especially useful in the Dutch energy sector, where we’re increasingly moving toward distributed systems and have to make conscious choices about how we coordinate long‑running workflows.
👉🏻This post takes the saga comparison matrix from Software Architecture: The Hard Parts, shares a few observations on the trade-offs behind the eight saga patterns, and adds some movie-style analogies – as a small wink to the book’s whimsical saga names – just for fun.
What is a Saga?
A Saga coordinates long-running business workflows across distributed services. Each service does its own small part of the work, and they communicate with each other through commands or events. If something goes wrong halfway through, the Saga can undo or correct earlier steps to keep things consistent. In short, a Saga is a structured way to handle distributed transactions.
A Saga acts as a workflow coordinator for distributed transactions
What are Distributed Transactions?
A distributed transaction is when one business action depends on several different services or databases working together. For example, when a new customer signs up:
- the Account Service creates the user account
- the Billing Service creates the billing profile
- the Email Service sends a welcome email
Even though different services are involved, the user still expects it to feel like one smooth operation.
A distributed transaction is a single business operation that spans multiple services – where everything needs to succeed or be undone together
Sagas and Distributed Transactions
Here’s the problem: distributed systems are hard to coordinate perfectly 🤔.
Traditional databases were designed around strict ACID (Atomicity, Consistency, Isolation, Durability) guarantees:
- either everything succeeds
- or everything fails immediately
That works well when a single database controls everything. But modern distributed systems with multiple serves and databases tend to follow a BASE-style mindset (Basically Available, Soft state, Eventually consistent), trading strict consistency for resilience and scalability. In these systems:
- services run independently
- networks can fail
- messages can arrive late
- keeping everything perfectly synchronized is expensive and slow
Sagas solve this by taking a more flexible approach. Instead of requiring every step to succeed instantly, a Saga accepts that some steps may finish later or occasionally need to be undone. If one part fails, the Saga can trigger follow-up actions to fix or reverse earlier work. Rather than aiming for perfect instant consistency, Sagas focus on keeping the overall business process reliable and practical at scale.
A Saga is a practical way to coordinate distributed transactions when perfect consistency across services is impossible or too expensive.
Eight Saga Pattern types
Sagas are one of the main mechanisms for controlling runtime forces like:
- Communication (sync vs async)
- Consistency (atomic vs eventual)
- Coordination (orchestration vs choreography)
Those three forces of runtime inter-service dependency combine into eight distinct saga patterns, each enabling a qualitative analysis of the trade-offs in communication, consistency, and coordination. This qualitative perspective comes together in the saga comparison matrix, which shows how each pattern balances these forces.
Saga Comparison Matrix
The eight saga patterns are all about the three coupling drivers: communication, consistency, and coordination. You cannot treat each of these forces in isolation; it is their combined effect that matters. Alongside the four primary trade-off concerns – coupling, complexity, responsiveness/availability, and scale/elasticity – evaluated against the three forces of communication, consistency, and coordination, this leads to the following comparison matrix:
This matrix helps you choose the most appropriate saga type based on your requirements. One option is to implement the two most promising variations based on qualitative analysis, and then validate them with quantitative analysis to ensure the system behaves the way you expect.
Observations
The matrix visualizes some interesting observations:
- The extremes tell the clearest story: Epic Saga and Anthology Saga sit at opposite corners of every dimension. Epic Saga is the most coupled, least scalable pattern while Anthology Saga is the least coupled, most scalable. They are architectural mirror images of each other.
- The atomic consistency tax: Every pattern with atomic consistency: Epic Saga, Fantasy Fiction, Phone Tag, and Horror Story scores red on responsiveness or scalability or both. Atomicity is never free in distributed systems.
- The sweet spot: Fairy Tale Saga and Parallel Saga stand out as the most balanced patterns – good scalability, manageable complexity, and reasonable responsiveness. Not perfect on any single dimension but no catastrophic red scores either – these are the patterns most architects should default to. Anthology Saga is the scalability champion, scoring the highest on scalability and lowest on coupling, but it pays a real complexity price – only worth it when throughput and scale are the primary drivers.
- The anti-pattern is visible at a glance: Horror Story Saga is an anti-pattern because it demands the hardest consistency guarantee (atomicity) while using the two approaches least suited to achieving it: asynchronous communication and choreography
- The choreography trade-off: Choreographed patterns consistently score better on coupling but worse on complexity – removing the orchestrator reduces dependencies but pushes coordination burden into every individual service, raising complexity across the board.
Personal note
Personally, I tend to favor choreographed sagas, especially the Anthology Saga. I like that each service owns its own small part of the story and reacts to domain events independently. That lines up naturally with bounded contexts and team autonomy, and it keeps coupling low, particularly in larger business flows that span multiple teams.
One might argue that this pattern is a poor fit for complex workflows because the coordination is harder to follow (the above red complexity bullet). But hard‑to‑follow coordination is often a hint that the system boundaries are off. Instead of fighting that complexity with even more complex orchestration, it’s usually better to break the big workflow down into micro‑workflows: small, focused processes that communicate through events rather than through one tight, central control flow. Decoupling responsibility means each service owns how it reacts to an event, including how it handles failures. Instead of one monolithic coordinator, you end up with a cooperating set of services that communicate through events, making the system more resilient, easier to evolve, and often simpler to debug.
Architecturally, the deeper lesson is to break complex problems into small, well-understood parts and refine the boundaries until the design fits naturally. Choreography and micro-workflows then become a good way to compose those parts into a clean, maintainable system. If choreography still feels too complex, the problem is usually the domain and workflow boundaries, not the lack of orchestration. Fix the design first; only then decide whether you need an orchestrator💡.
Don’t solve complex problems with complex solutions – challenge the problem first
If Saga Patterns Were Movies
