Manu's Vault

Phone Tag Saga Pattern

3 min readStatus:Seedling

Core Idea

The Phone-Tag Saga Pattern coordinates distributed transactions with synchronous communication, eventual consistency, and choreographed coordination—services pass control sequentially like leaving messages, without a central orchestrator.

The Phone-Tag Saga Pattern (SAC) coordinates distributed transactions with three defining properties: Synchronous communication (services make blocking request-response calls directly to each other), Eventual consistency (transactions achieve consistency over time through compensating transactions), and Choreographed coordination (services react to domain events and call downstream services directly without a central orchestrator). Named “Phone Tag” because services pass control sequentially—each completes its local transaction and synchronously hands off to the next service, creating a bouncing-baton pattern with no central dispatcher.

How It Works

  • Decentralized service chain: Each service knows its next downstream service based on domain rules; no orchestrator directs traffic
  • Synchronous hand-off: Service A completes its local transaction, then makes a blocking call to Service B, which calls Service C—control passes sequentially through the chain
  • Eventual consistency through compensation: If any step fails, previously completed services must execute compensating transactions; each service independently manages its own rollback logic
  • No central state: Overall saga state is distributed across services; understanding progress requires correlating logs across the chain
  • Sequential blocking: Each service waits synchronously for all downstream confirmations before returning—latency accumulates through the full chain depth

Trade-Offs

Advantages:

  • No orchestrator overhead—eliminates single point of failure and operational complexity of a separate coordinator
  • Service autonomy—each service decides its next action based on local domain logic
  • Simpler than fully asynchronous choreography—synchronous calls provide immediate feedback

Disadvantages:

  • Accumulated latency—total saga time is the sum of all synchronous hops plus network overhead
  • Poor scalability—services spend time blocked waiting rather than processing new requests
  • Tight temporal coupling—all services in the chain must be available simultaneously
  • Difficult to debug—no central saga state; failure investigation requires correlating distributed logs

Sources

  • Ford, Neal; Richards, Mark; Sadalage, Pramod; Dehghani, Zhamak (2022). Software Architecture: The Hard Parts - Modern Trade-Off Analyses for Distributed Architectures. O’Reilly Media. ISBN: 978-1-492-08689-5.

    • Chapter 12: “Transactional Sagas”, pages 325-330

  • Garcia-Molina, Hector and Salem, Kenneth (1987). “Sagas.” ACM SIGMOD Record, Vol. 16, No. 3, pp. 249-259. DOI: 10.1145/38714.38742

  • Richardson, Chris (2025). “Pattern: Saga.” Microservices.io.

  • Newman, Sam (2021). Building Microservices: Designing Fine-Grained Systems, 2nd Edition. O’Reilly Media. ISBN: 978-1-492-03402-5.

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks