# Revision and Interview Questions — Event-Driven Architecture & CQRS

Source: https://www.skillbyai.com/en/event-driven-architecture/p-revision

> Recall event-driven and CQRS concepts quickly for exams and interviews.

## Cheat sheet

**EDA**: publish facts; consumers react; removes temporal coupling; costs async complexity and eventual consistency. **Terms**: command (request, may fail) vs event (past-tense fact) vs query. **Fowler's four**: event notification, event-carried state transfer, event sourcing, CQRS. **Event design**: envelope with ID, type, version, source, time, subject, correlation; CloudEvents; schemas with compatibility rules; thin vs fat; domain vs integration events. **Brokers**: queues (competing consumers, ack and delete) vs logs (partitions, offsets, consumer groups, replay). **Delivery**: at-most/at-least/effectively-once; idempotent consumers; ordering per key; retries, DLQ. **Reliability**: dual-write problem → transactional outbox (polling or CDC), inbox, idempotency keys; sagas with compensations, choreography vs orchestration. **CQRS**: separate write and read models; projections; levels 1–4; eventual consistency in the UI. **Event sourcing**: events as source of truth, fold to state, optimistic concurrency, snapshots, upcasting, crypto-shredding. **Ops**: correlation and trace context, consumer lag, contract tests, AsyncAPI.

## Common interview questions

Answer each in two or three sentences with an example.

```text
1. Event vs command: what is the difference, and why does naming matter?
2. What problem does the transactional outbox solve?
3. Why is exactly-once delivery hard, and how do you get effectively-once processing?
4. How do you keep events for one entity in order?
5. Choreography vs orchestration for sagas: trade-offs?
6. What is CQRS, and does it require event sourcing?
7. How would your UI handle eventual consistency after a command?
8. What are snapshots and upcasters in event sourcing?
9. How would you evolve an event schema without breaking consumers?
10. How do you trace a business transaction across asynchronous services?
```

## Pair every pattern with its cost

Interviewers listen for trade-offs: "an outbox guarantees publication but adds a relay and at-least-once delivery, so consumers must be idempotent" is far stronger than naming the pattern alone.

**Quiz:** Which pairing correctly matches a problem to its pattern?

- [ ] Duplicate deliveries → schema registry
- [ ] Slow reads → saga compensation
- [ ] Out-of-order events → crypto-shredding
- [x] Lost events from dual writes → transactional outbox

*Answer:* Lost events from dual writes → transactional outbox. The outbox removes the dual-write gap between database changes and published events.