Event-Driven Architecture Interview Questions
Interview questions on events, outbox, idempotency, CQRS, event sourcing and eventual consistency, with practical answers.
Event-driven architecture interview questions
EDA questions are common in senior backend and system design interviews. Interviewers look for an understanding of failure modes, not just diagrams.
1. What is event-driven architecture?
A style where services communicate by publishing and consuming events — immutable facts about things that happened — through a broker, rather than calling each other directly. It decouples producers from consumers.
2. Event vs command?
An event states something happened (OrderPlaced) and can't be rejected. A command requests an action (PlaceOrder) and may be rejected. Events are broadcast to any interested consumer; commands target one handler.
3. What is the dual-write problem?
Updating a database and publishing to a broker are two separate operations with no shared transaction, so one can succeed while the other fails, leaving the system inconsistent.
4. How does the transactional outbox pattern work?
The service writes the business change and an outbox row containing the event in the same database transaction. A relay (polling worker or change data capture) publishes outbox rows to the broker and marks them sent.
5. What delivery guarantee does the outbox provide?
At-least-once. A relay can publish and crash before marking the row sent, causing duplicates — so consumers must be idempotent.
6. How do you make a consumer idempotent?
Record processed event IDs in a deduplication (inbox) table within the same transaction as the side effect, rely on unique constraints, use naturally idempotent updates, or apply version checks.
7. Explain CQRS.
Command Query Responsibility Segregation separates the write model, which enforces business rules, from read models optimised for queries. Read models are typically built by projections that consume events.
8. What is a projection?
A component that consumes events and updates a read-optimised view — for example, revenue per course for a dashboard. Projections must be idempotent and can be rebuilt by replaying events.
9. What is event sourcing?
Storing an append-only log of domain events as the source of truth and deriving current state by replaying them, instead of storing only the latest state.
10. How do you handle concurrency in event sourcing?
Optimistic concurrency: appends include the expected stream version, and the store rejects the write if the stream has moved on. The client reloads and retries.
11. Why use snapshots?
To avoid replaying a very long event stream on every load. Load the latest snapshot and apply only later events; events remain the source of truth.
12. CQRS vs event sourcing — are they the same?
No. CQRS separates reads and writes; event sourcing changes how the write side stores data. They combine well but can be used independently.
13. How do you evolve event schemas safely?
Make additive, optional changes; include an explicit version; have tolerant consumers; upcast old events on read; use a schema registry with compatibility checks; publish a new event type for changes in meaning.
14. How do you handle event ordering?
Partition events by entity key so all events for one entity are ordered (e.g. Kafka partitions), include sequence numbers, and have consumers detect and handle gaps or out-of-order versions.
15. How do you debug a request across many asynchronous services?
Propagate a correlation ID in every event, use distributed tracing (e.g. OpenTelemetry with trace context in message headers), log event IDs, and monitor consumer lag and dead-letter queues.
16. What is a dead-letter queue?
A queue where messages that repeatedly fail processing are moved after a retry limit, so they don't block the stream. Teams inspect, fix and replay them.
17. When would you avoid event-driven architecture?
For simple CRUD systems, operations needing immediate strong consistency, or small teams without the capacity to operate brokers and handle eventual consistency.
Practice tip
Implement the outbox and an idempotent consumer with SQLite from this tutorial, then simulate a crash between publishing and marking the row sent. Explaining why your consumer still produces the right result is an excellent interview answer.