System Design · Architecture under constraints
What is event-driven architecture and what are its failure modes?
Short answer
Event-driven architecture lets services react to facts published by others instead of calling them directly. It reduces coupling but introduces eventual consistency, duplicate delivery, ordering and observability problems.
An event is a statement that something happened, such as OrderPlaced or PaymentCaptured. A command is a request to do something, such as ChargeCard. Event-driven systems publish events and let interested services react, so the producer does not need to know every consumer.
Two coordination styles
- Choreography: each service listens and reacts, with no central coordinator, which is flexible but makes the overall flow hard to see
- Orchestration: a coordinator calls each step and tracks state, which is easier to reason about but adds a central component
- Events should be immutable facts with a stable schema and an event id
- Consumers should be idempotent because delivery is usually at-least-once
The main cost is that the system is now eventually consistent. A user may see an order before the inventory projection updates, or a notification may arrive before the UI refresh. The product needs a story for that window: optimistic UI, a pending state, or a read model that waits for the needed event.
Schema evolution is another failure mode. Adding a required field breaks old consumers; changing the meaning of a field silently corrupts projections. Use versioned event types, additive changes, a schema registry and a compatibility policy. Keep a correlation id and a causation id so one user action can be traced across services.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1When would you choose orchestration over choreography?
- 2How do you trace one user action across many services?
- 3How do you evolve an event schema without breaking consumers?
- 4Why can publishing after a database commit lose events?
Say it in the interview
Event-driven architecture publishes facts and lets services react, which reduces direct coupling but makes the system eventually consistent. I choose choreography for simple independent reactions and orchestration when a flow needs central visibility. Consumers must be idempotent, and events need stable schemas plus correlation ids for tracing. I also publish through an outbox so a committed state change and its event cannot diverge.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live System Design mock interview and get scored feedback on depth, clarity and confidence.