Manu's Vault

Horror Story Pattern

6 min readStatus:Seedling

Core Idea

The Horror Story Pattern is a distributed transaction coordination pattern: asynchronous communication, atomic consistency per step, and choreographed coordination where services react to events without a central orchestrator.

The Horror Story Pattern is a distributed transaction coordination pattern characterized by three defining properties: Asynchronous communication (services exchange events via message queues or event streams), Atomic consistency (each step executes as an ACID transaction with immediate consistency), and Choreographed coordination (services react to events without central orchestrator—each service knows its role and publishes events when complete). Named “Horror Story” because like anthology horror films where disconnected characters independently respond to supernatural events without coordination, services react autonomously to domain events, creating emergent workflow behavior with no single “storyteller” controlling the narrative.

How It Works

  • Event-driven choreography with atomic steps: Services subscribe to domain events (e.g., “OrderCreated”, “PaymentReceived”) and react by executing local ACID transactions, then publishing new events
  • No central orchestrator: Unlike orchestrated patterns, no single component maintains saga state—workflow emerges from services reacting to events according to business rules
  • Asynchronous event propagation: Events flow through message broker (Kafka, RabbitMQ, EventBridge) with temporal decoupling—publishers don’t block waiting for consumers
  • Strong consistency within steps: Each service’s transaction commits atomically before publishing next event—no eventual consistency windows within individual steps
  • Distributed compensating logic: When failure occurs, detecting service publishes compensating event (e.g., “PaymentFailed”)—other services react by undoing their changes
  • Event correlation without central state: Services track saga progress using correlation IDs embedded in events—but no single component knows complete saga state
  • Emergent workflow behavior: Complete saga flow emerges from distributed event reactions—difficult to visualize or debug entire sequence

When to Use

  • Highly decoupled domain services: Bounded contexts that should remain independent—each service owns its domain logic including saga participation rules
  • Long-running sagas with atomic guarantees: Multi-hour workflows (supply chain coordination, approval chains) requiring strong consistency but without orchestrator bottleneck
  • Event-driven architecture mandates: Systems already built on event sourcing or event-driven patterns where adding orchestrator creates architectural inconsistency
  • Scalable event processing: Workflows where asynchronous event propagation enables high throughput without central coordinator bottleneck
  • Domain events drive business logic: Business rules naturally expressed as reactions to domain events (e.g., “when inventory reserved, charge payment”)

Trade-Offs

Advantages:

  • Maximum service autonomy: No orchestrator dependency—services independently evolve their event reaction rules
  • No single point of failure: Unlike orchestrated patterns, no central coordinator to fail—saga continues if message broker remains available
  • Natural fit for event-driven systems: Leverages existing event infrastructure without introducing orchestration complexity
  • High throughput: Asynchronous event processing enables parallel service execution where business rules allow

Disadvantages:

  • Extremely difficult debugging: No centralized saga state—must correlate events across message logs to reconstruct workflow execution
  • Unclear saga boundaries: Emergent behavior makes it hard to identify where saga starts/ends—difficult to reason about complete workflow
  • Distributed compensating logic: Failure handling scattered across services—no single place to understand compensation sequence
  • Cyclic dependency risks: Services reacting to each other’s events can create circular event chains—requires careful design to prevent infinite loops
  • No saga timeout management: Without orchestrator, difficult to detect “stuck” sagas where expected event never arrives

Example

E-commerce order processing: Order, Payment, Inventory, Shipping services coordinate via domain events.

  1. Order service receives HTTP POST, creates order atomically, publishes “OrderCreated” event with correlation ID
  2. Inventory service consumes event, reserves stock via ACID transaction, publishes “InventoryReserved” event
  3. Payment service consumes event, charges card atomically, publishes “PaymentCharged” event
  4. Shipping service consumes event, creates shipment atomically, publishes “ShipmentCreated” event
  5. If payment fails, Payment service publishes “PaymentFailed” event
  6. Inventory service consumes failure event, releases reservation, publishes “InventoryReleased” event
  7. Order service consumes failure events, marks order failed—no orchestrator coordinating compensations

No service knows complete saga state—each reacts to events according to local business rules. Debugging requires correlating events across broker logs.

Comparison to Other Saga Patterns

  • vs. Fantasy Fiction Saga (AAO): Horror Story uses choreographed events where services react autonomously; Fantasy Fiction has orchestrator managing state and publishing commands
  • vs. Phone Tag Saga (SAC): Horror Story uses asynchronous events for temporal decoupling; Phone Tag uses synchronous blocking calls between choreographed services
  • vs. Anthology Saga (AEC): Horror Story guarantees atomic consistency with immediate commits; Anthology accepts eventual consistency where services may see stale data during event processing

Related Saga Patterns

Compare to Epic-Saga-Pattern (SAO), Phone-Tag-Saga-Pattern (SAC), Fairy-Tale-Saga-Pattern (SEO), Time-Travel-Saga-Pattern (SER), Fantasy-Fiction-Saga-Pattern (AAO), Parallel-Saga-Pattern (AEO), and Anthology-Saga-Pattern (AEC).

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 Horror Story Pattern (AAC) 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
    • Choreography-based saga implementations where services publish domain events triggering local transactions
    • Notes lack of isolation and need for compensating transactions in choreographed designs

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

  • Fowler, Martin (2017). “What do you mean by ‘Event-Driven’?” MartinFowler.com.

    • Available: https://martinfowler.com/articles/201701-event-driven.html
    • Event Notification pattern—systems send events to notify others of domain changes without expecting coordinated response
    • Warns about “invisible workflows” where logical flow emerges from event chains without explicit program text

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

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

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