Microservices have been hot for a decade, and Saga has almost become the standard answer for distributed transactions. But in 2026, more and more architects are re-examining this pattern.
What Problem Does Saga Solve
In the monolith era, database transactions (ACID) naturally guaranteed consistency. After splitting into microservices, a single business operation may span multiple services and databases—there's no global transaction anymore.
The Saga approach: break a large transaction into multiple local transactions, each with a corresponding compensating action. If something fails, execute compensations in reverse order.
Order Service (Create Order) → Inventory Service (Deduct Stock) → Payment Service (Charge)
↓ ↓ ↓
(Cancel Order) ←──────── (Rollback Stock) ←────── (Refund)
The Problems with Saga
As you use it, you'll run into several pitfalls:
1. Compensation logic isn't always feasible. Can you retract an SMS that's already been sent? Can you take back a coupon that's already been issued? Many business operations are irreversible.
2. Complexity explodes. For a Saga spanning N services, the combinations of failure scenarios grow exponentially. Test coverage becomes nearly impossible to complete.
3. Intermediate states are exposed to users. The order is created but stock hasn't been deducted yet—users see a half-finished product, and then when they refresh, the order is gone.
4. It amplifies technical debt. Saga couples business logic with coordination logic. When the business changes, the compensation logic has to change too—and it's a chain reaction.
The New Approach in 2026: Dynamic Consistency Boundaries
AxonIQ has proposed a concept called Dynamic Consistency Boundaries (DCB).
Core idea: Don't lock down data ownership at design time. Traditional Domain-Driven Design Aggregates freeze your understanding of the business at the moment of definition—but the business evolves.
The DCB approach: - Manage state changes uniformly through event streams - Consistency rules are dynamically defined by "tags," not determined at compile time - Decide boundaries when consistency is needed, rather than splitting them in advance
| Dimension | Saga | DCB |
|---|---|---|
| Data boundaries | Fixed at compile time | Dynamic at runtime |
| Compensation complexity | High (exponential combinations) | Low (event streams are naturally traceable) |
| Cost of business changes | High (modify coordination logic) | Low (modify tag rules) |
| Intermediate states | Visible to users | Isolated by event streams |
Not to Say Saga Is Dead
Saga is still appropriate in some scenarios: - Few services, simple flows (2-3 steps) - Compensation operations are clear and reliable (e.g., pure financial scenarios) - The team is already familiar with Saga frameworks
But in complex business flows, if you find Saga getting more and more painful to maintain—it's not that you're using it wrong, it's that the pattern itself has a ceiling.
In 2026, treating "we need Saga" as a code smell might save you a lot of detours.
References:
Comments
Comments are closed.