Event-Driven Architecture Explained: Events, Commands, and the Tradeoffs Nobody Mentions

Event-driven architecture decouples your services by replacing synchronous calls with published events. Instead of one handler calling seven downstream services after a payment succeeds, you announce the fact and let each service react independently. The core distinction: events are immutable facts, commands are directives.

Fowler's taxonomy splits EDA into three event patterns: notification (thin, receiver calls back), state transfer (fat, receiver caches locally), and event sourcing (full replay log). Topology matters too — choreography works for simple fan-outs, orchestration wins when you need explicit ordering and rollback logic.

The honest tradeoffs: debugging causality requires correlation IDs and distributed tracing from day one, eventual consistency is visible to users, and the dual-write problem will silently lose events unless you use a transactional outbox. Worth the complexity when your synchronous handler can't keep up.