Consistency and Workflow Boundaries

Distributed workflows expose whether a service split is truly workable or only looks clean in a diagram. Chapter 8 focuses on the moment a business process crosses several services and the system has to handle partial completion, delayed updates, retries, and recovery without pretending the whole workflow is one local transaction.

Read the lessons in order. The first explains why transaction boundaries become harder once state is distributed. The second turns eventual consistency into a practical design constraint instead of a vague slogan. The third compares saga orchestration and choreography. The fourth shows how compensation and failure design determine whether a workflow is survivable in production.

If a proposed decomposition seems clean until someone asks, “What happens when step three fails after step two already committed?”, this chapter is where the real architectural work starts.

In this section

• Transaction Boundaries in a Distributed World
  A practical lesson on why local ACID transactions are easy inside one boundary, why distributed atomicity is expensive, and how transaction needs should influence service decomposition.
• Eventual Consistency as a Design Constraint
  A practical lesson on eventual consistency, when it is acceptable, how it affects user experience, and why distributed systems need explicit in-flight states instead of pretending all updates are instant.
• Sagas, Orchestration, and Choreography
  A practical lesson on saga-based workflow coordination, the trade-offs between orchestration and choreography, and how to choose a coordination style that matches workflow complexity.
• Designing for Compensation and Failure
  A practical lesson on compensation, retries, duplicates, timeout handling, and manual intervention in distributed workflows that cannot rely on one global rollback.