Event-Driven Architecture
Services communicate by publishing facts (events) — loose coupling, async scaling, and natural audit trails.
Interview tip Lead with a 30-second definition, then one real system example and name 2–3 designs where Event-Driven Architecture is non-negotiable.
① What it is (30 seconds)
Services communicate by publishing facts (events) — loose coupling, async scaling, and natural audit trails.
② How it works in system design
Event producer emits immutable event (OrderCreated). Multiple consumers react independently. Event bus (Kafka) stores history. Choreography vs orchestration for multi-step flows.
Typical placement
Client→Edge / Gateway→Event-Driven→Services→Data stores
③ Concrete system design example
Scenario: Order placed → inventory reserved, payment charged, email sent, analytics updated — four consumers on OrderCreated without order service calling each synchronously.
④ Important interview Q&A
| Question | Answer |
|---|---|
| Events vs commands? | Events are facts (past tense); commands request action — different retry semantics. |
| Orchestration vs choreography? | Orchestrator coordinates saga steps; choreography each service listens and reacts — more decoupled but harder to trace. |
| Event versioning? | Add fields compatibly; consumers ignore unknown fields; use schema registry. |
⑤ Seen in these system designs
- Notifications — event triggers
- Payment System — outbox events
- News Feed — fan-out events
In interviews, after explaining the concept, say: "This shows up directly in …" and link two designs.
⑥ Revision checklist
- Event naming
- Choreography vs orchestration
- Schema evolution
- Idempotent consumers