Manu's Vault

Fantasy Fiction Saga Pattern

5 min readStatus:Seedling

Core Idea

The Fantasy Fiction Saga Pattern coordinates distributed transactions with asynchronous communication, atomic consistency per step, and a central orchestrator that coordinates via message queues without blocking.

The Fantasy Fiction Saga Pattern is a distributed transaction coordination pattern characterized by three defining properties: Asynchronous communication (orchestrator sends commands via message queues without blocking), Atomic consistency (each step executes as an ACID transaction with immediate consistency), and Orchestrated coordination (central orchestrator manages workflow state and decides next steps). Named “Fantasy Fiction” because like serialized fantasy novels, the story unfolds in distinct chapters (messages) that arrive independently while maintaining a coherent narrative arc controlled by a single author (the orchestrator).

How It Works

  • Central orchestrator with asynchronous messaging: Orchestrator coordinates the saga via message queues—publishes commands, receives replies, maintains state—without blocking on responses
  • Non-blocking coordination: Orchestrator sends command and immediately continues processing other sagas rather than waiting—enables high throughput and concurrent saga coordination
  • Each step is atomic: Domain services execute ACID transactions locally—changes commit or rollback immediately within service’s bounded context
  • Message-driven state progression: Orchestrator consumes completion events from reply channels, updates workflow state, publishes next command based on business rules
  • Compensating transactions on failure: If step fails, orchestrator asynchronously publishes compensation commands in reverse order (LIFO) to undo previous commits
  • Strong consistency at each step: No eventual consistency windows within saga steps—committed data is always in well-defined state (progressing forward or compensating backward)
  • Temporal decoupling with atomic guarantees: Unlike Epic Saga’s synchronous blocking, services don’t need simultaneous availability while maintaining atomic consistency

When to Use

  • High-throughput workflows requiring strong consistency: Payment processing where atomic steps are critical but synchronous blocking creates unacceptable latency
  • Long-running sagas with atomic steps: Multi-hour workflows (loan approvals, supply chain) where holding synchronous connections is infeasible
  • Variable service processing times: Domain services with unpredictable latency (external APIs, batch processes) where orchestrator cannot block waiting
  • Orchestrator must scale independently: Asynchronous messaging prevents bottlenecks—can coordinate thousands of concurrent sagas
  • Resilience to temporary unavailability: Message queues buffer commands when services are temporarily down

Trade-Offs

Advantages:

  • Higher throughput: Orchestrator doesn’t block waiting—coordinates many concurrent sagas with lower latency than Epic Saga
  • Temporal decoupling: Services can be temporarily unavailable; queued messages wait for recovery
  • Strong consistency per step: Maintains ACID guarantees, avoiding eventual consistency complexity within steps
  • Centralized error handling: Single orchestrator manages failures, compensations, and audit trails

Disadvantages:

  • Increased complexity: Requires message broker, correlation IDs, reply channels, idempotent message handling
  • Harder debugging: Asynchronous messaging complicates tracing—must correlate messages across queues
  • Single point of failure: Orchestrator must be highly available; failure requires state recovery
  • Message ordering challenges: Out-of-order delivery requires sequence tracking or deduplication

Example

E-commerce order processing: Orchestrator coordinates payment, inventory, shipping via message queues.

  1. Orchestrator publishes “reserve-inventory” command to inventory queue with correlation ID
  2. Orchestrator immediately processes other sagas without blocking
  3. Inventory service consumes message, executes ACID transaction, publishes “inventory-reserved” reply
  4. Orchestrator receives reply, updates saga state, publishes “charge-payment” command
  5. Payment service charges card atomically, publishes “payment-charged” reply
  6. Orchestrator publishes “create-shipment” command
  7. If shipping fails, orchestrator asynchronously publishes “refund-payment” then “release-inventory” compensations
  8. Orchestrator publishes “order-completed” or “order-failed” with audit trail

Orchestrator never blocks—coordinates hundreds of concurrent sagas while maintaining atomic consistency per step.

Comparison to Other Saga Patterns

  • vs. Epic Saga (SAO): Fantasy Fiction uses asynchronous messaging for higher throughput; Epic uses synchronous blocking calls with lower latency per saga
  • vs. Parallel Saga (AEO): Fantasy Fiction guarantees atomic consistency with immediate commits; Parallel accepts eventual consistency where steps may see stale data
  • vs. Horror Story (AAC): Fantasy Fiction has centralized orchestrator managing state; Horror Story uses choreographed event chains where services react without central coordinator

Related Saga Patterns

Compare to Epic-Saga-Pattern (SAO), Parallel-Saga-Pattern (AEO), Horror-Story-Pattern (AAC), Fairy-Tale-Saga-Pattern (SEO), Time-Travel-Saga-Pattern (SER), Phone-Tag-Saga-Pattern (SAC), and Anthology-Saga-Pattern (AER) when created.

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-345
    • Defines Fantasy Fiction Saga (AAO) as one of eight saga variations based on communication style, consistency model, and coordination approach

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

    • Available: https://microservices.io/patterns/data/saga.html
    • Orchestration-based saga implementations with asynchronous messaging
    • Notes atomic database updates with message publishing require Transactional Outbox or Event Sourcing patterns

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

  • Fortuna, Emily (2021). “Saga Design Pattern Explained.” Temporal.io Blog.

  • Hohpe, Gregor and Woolf, Bobby (2003). Enterprise Integration Patterns. Addison-Wesley. ISBN: 978-0321200686.

  • Amazon Web Services (2025). “Standard vs Express Workflows.” AWS Step Functions.

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