Event-driven architecture

Event-driven architecture publishes facts about completed changes so producers and consumers evolve with loose coupling. It enables scaling reactions, audit trails, and integrations but introduces eventual consistency, duplicate delivery, and ordering challenges. Design explicit schemas, idempotent consumers, and dead-letter handling.

On interviews: compare events with commands and with synchronous REST. Discuss outbox pattern, replay, and poison messages.

Common pitfalls: chatty event streams without business meaning; missing consumer versioning; treating message bus as database.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Events name past-tense business facts.
• Consumers idempotent with deduplication keys.
• Schema registry or contract tests for payloads.
• Observability on lag, DLQ, and replay procedures.