Revision and Interview Questions

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.

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.

Quick check: Which pairing correctly matches a problem to its pattern?

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