Event-Driven Architecture — Building Reactive Systems

In a request-driven architecture, Service A calls Service B and waits for a response. If Service B is slow or down, Service A is stuck. In an event-driven architecture, Service A publishes an event and moves on. Service B consumes the event whenever it’s ready. The services are decoupled in time and availability.

This decoupling is what makes event-driven architecture powerful — and what makes it complex. You trade synchronous simplicity for asynchronous resilience. The system becomes more fault-tolerant but harder to reason about.

The Four Patterns

“Event-driven” isn’t one thing — it’s a family of patterns with different tradeoffs. Most teams start with event notifications, which is the simplest. Event sourcing and CQRS are powerful but complex, and you should only reach for them when the simpler patterns aren’t enough.

Event-Driven Architecture Patterns

Event Notification

Service A → "Order Created" event → Service B reacts

Thin event, just a signal. Consumer fetches full data if needed.

Low coupling, small payloads

Event-Carried State Transfer

Service A → "Order Created" + full order data → Service B caches locally

Fat event, carries all data. Consumer never calls back to producer.

No runtime dependency, eventual consistency

Event Sourcing

All changes stored as events → Current state = replay all events

Events ARE the source of truth. State is derived, not stored directly.

Full audit trail, time travel, replay capability

CQRS

Write model (commands) → Events → Read model (queries)

Separate write and read paths optimized independently.

Scale reads and writes independently, tailored views

Event notification is where 90% of teams should start. Service A publishes a small event (“OrderCreated, id: 123”). Service B subscribes, receives the event, and fetches additional data from Service A if needed. The events are cheap to produce and consume, and the coupling is minimal.

Event sourcing is a fundamentally different data model. Instead of storing the current state of an entity (Order: status=shipped), you store every event that happened to it (OrderCreated → ItemAdded → PaymentProcessed → Shipped). Current state is derived by replaying events. This gives you a complete audit trail, the ability to rebuild state at any point in time, and the option to create new read models from historical events. But it adds significant complexity: event schema evolution, snapshot management, and eventual consistency everywhere.

The honest advice: use event notifications liberally — they’re a proven pattern for decoupling services. Use event sourcing only when you have a genuine need for audit trails, temporal queries, or event replay. Using event sourcing “just because” adds enormous complexity with no payoff.