Overview
In event-driven architecture (EDA), services communicate by producing and reacting to events: records of something that happened, like OrderPlaced or PaymentFailed. Producers publish events to a broker without knowing who consumes them, and consumers react independently. This decouples services in time, availability, and knowledge of each other.
EDA enables extensibility (add consumers without changing producers), resilience (consumers can be down and catch up), and scalability. The costs are eventual consistency, harder end-to-end reasoning and debugging, event schema governance, and the need for idempotent consumers. Choreography (services react to each other's events) and orchestration (a coordinator directs steps) are two ways to build multi-step workflows.
When something happens, the town crier announces it in the square. The baker, the blacksmith, and the tax collector each decide what to do with the news. The crier does not need to know who listens.
When to use it
- Many services need to react to the same business events.
- Workflows that can be asynchronous.
- Integrating systems owned by different teams.
- Real-time data propagation (analytics, search, caches).
Where it shows up in interviews
Recognize it when: order placement triggers many downstream actions.
- Design an e-commerce order pipeline
- Design a food delivery system
Recognize it when: keep search, cache, and analytics in sync.
- Design product search indexing
- Design a real-time analytics system
Where it is used in real software
Uses Kafka-based event streams for trips, pricing, and dispatch across thousands of services.
EventBridge, SNS, and SQS enable event-driven serverless applications.
Debezium turns database changes into events so other systems react without dual writes.
Key terms
- Event
- Immutable fact about the past, in past tense.
- Event notification vs event-carried state
- Thin event with an ID vs event containing the full data.
- Choreography
- Services react to events with no central coordinator.
- Orchestration
- A coordinator sends commands and tracks workflow state.
- Schema registry
- Stores and validates event schemas and versions.
How it works, step by step
- 1Identify business events
Event storming: OrderPlaced, PaymentCaptured, OrderShipped.
- 2Publish reliably
Outbox pattern or CDC.
- 3Define schemas and versions
Backward-compatible evolution.
- 4Build idempotent consumers
Deduplicate by event ID.
- 5Observe the flow
Correlation IDs, tracing, lag monitoring, DLQs.
STEP 1Orders publishes OrderPlaced.
Choreography vs orchestration
Two ways to run a multi-step workflow
| Aspect | Choreography | Orchestration |
|---|---|---|
| Control | Distributed: each service reacts | Central coordinator |
| Coupling | Loose | Coordinator knows all steps |
| Visibility of flow | Hard to see end to end | Explicit in one place |
| Best for | Simple flows, many independent reactions | Complex flows with compensation |
| Tools | Kafka, SNS, EventBridge | Temporal, Step Functions, Camunda |
NOWAspect: Control | Choreography: Distributed: each service reacts | Orchestration: Central coordinator
Use choreography for fan-out reactions and orchestration for business-critical workflows that need clear state and compensation.
Implementation
{ "specversion": "1.0", "id": "evt_01J9ZK4Q7", "source": "shop.orders", "type": "com.shop.order.placed.v1", "time": "2026-09-14T10:15:00Z", "subject": "order/o-981", "datacontenttype": "application/json", "data": { "orderId": "o-981", "customerId": "c-42", "totalCents": 4599, "currency": "USD", "items": [{ "sku": "sku-1", "qty": 2 }] }}Complexity and performance
Independent of consumer count.
Typically ms to seconds.
Trade-offs
Loose coupling makes change easy locally but end-to-end flows harder to see and debug.
Services stay available independently but data across them is eventually consistent.
Variants and related techniques
Events as the source of truth.
Continuous processing of event streams (Kafka Streams, Flink).
Common mistakes
- Dual writes to DB and broker.
Fix: Use the outbox pattern or CDC.
- Events as remote procedure calls ('SendEmailNow').
Fix: Publish facts; let consumers decide.
- No schema governance.
Fix: Version schemas and validate with a registry.
Interview questions
What are the pros and cons of event-driven architecture?
Pros: loose coupling, extensibility, resilience to consumer outages, and scalability. Cons: eventual consistency, harder debugging and tracing, schema evolution, duplicate and out-of-order events requiring idempotent consumers.
Choreography or orchestration for checkout?
Orchestration is often better for checkout because it has several steps with compensations (refund, release stock) and needs clear state and timeouts; side effects like emails and analytics can be choreographed.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Model events for an order lifecycle | Easy | Event naming and payloads. |
| Design an event-driven food delivery backend | Hard | Choreography vs orchestration. |