Event-Driven Architecture

The Architectural Commitment

 instead of services calling each other,
 they react to FACTS flowing through a backbone:

        ┌────────── [event bus] ──────────┐
        │            │         │          │
   [orders]     [inventory] [billing]  [analytics]
        ▲            │         │
        └─ reacts ───┴─────────┘

 services publish what HAPPENED;
 other services decide what it MEANS for them.

 no service knows the full workflow — each owns its reaction.

The Choreography Principle

 EDA's signature: NO CENTRAL CONDUCTOR.

 OrderPlaced  → inventory reserves stock → StockReserved
              → billing charges card    → PaymentCaptured  
              → shipping prepares      → ShipmentCreated

 each step triggered by the previous event, independently owned.
 
 contrast (orchestration): one coordinator CALLS each service
 in sequence, holding the whole flow in its head.
 
 choreography wins on: decoupling, team autonomy, resilience
 (one consumer down ≠ flow halted).
 orchestration wins on: visibility ("where is order X?"),
 complex branching, rollback logic.

What You Gain

 □ TEMPORAL DECOUPLING: producers/consumers live independently;
   outages degrade gracefully (events queue up)
 □ EXTENSIBILITY: new capability = new subscriber; zero
   producer changes (add fraud detection overnight)
 □ LOAD SHAPING: spikes buffer in the bus instead of cascading
 □ NATURAL AUDIT LOG: events ARE history (feed into ES/analytics)

What It Costs

 the honest ledger:

 - EVENTUAL CONSISTENCY: inventory sees OrderPlaced milliseconds
   to minutes late. UIs and flows must tolerate in-between states.
 - DEBUGGING DIFFUSION: no single place shows a business flow —
   you reconstruct it from correlated traces/events.
 - VERSIONING DISCIPLINE: events outlive their producers'
   deploys; schemas must evolve compatibly forever.
 - TESTING COMPLEXITY: unit tests easy; the CHOREOGRAPHY needs
   contract + integration harnesses.
 - THE "WHY DID THIS HAPPEN" HUNT: chains of reactions need
   correlation ids or forensics suffers.

When EDA Is the Right Bet

Fit	Why
Many consumers per business fact	fan-out is native
Independent team cadences	contracts over coordination
Spiky workloads	buffering is structural
Audit/analytics-heavy domains	events double as the record

 weak fit:
 ✗ strict real-time consistency UX (stock counter at checkout!)
 ✗ tiny systems where HTTP calls are obviously enough
 ✗ workflows needing visible end-to-end state machines
   (use orchestration INSIDE an event-driven system — hybrid)

Interview Framing

“Design food-delivery order lifecycle” scored shape: bus-centric diagram, events named in past tense radiating from each service, explicit eventual-consistency callout WITH user-facing mitigation (optimistic UI states), extensibility example volunteered. Naming when you’d NOT choose EDA converts enthusiasm into judgment.