Skip to main content

Event-Driven Architecture

TL;DR​

Event-driven: Services communicate via events (async). Event sourcing: Store events (facts), rebuild state. CQRS: Separate read/write models. Benefits: Decoupling, scalability, audit trail.

Core Concepts​

1. Event-Driven vs Request-Response​

Request-Response (synchronous):

Event-Driven (asynchronous):

Benefits: Services don't wait, independently scalable.

2. Event Sourcing​

Traditional: Store current state only.

UPDATE account SET balance = 100 WHERE id = 123
-- Lost: How did balance become 100?

Event Sourcing: Store all events (immutable facts).

Event 1: AccountOpened (balance = 0)
Event 2: MoneyDeposited (amount = 150)
Event 3: MoneyWithdrawn (amount = 50)

Current balance = sum events = 100

Benefits:

  • ✅ Complete audit trail (replay history)
  • ✅ Time travel ("what was balance last week?")
  • ✅ Rebuild state from events

Trade-offs:

  • ❌ More complex
  • ❌ Can't delete events (GDPR challenge)

For deep dive: See your existing Event Sourcing guide

3. CQRS (Command Query Responsibility Segregation)​

Separate read and write models.

Why: Write model enforces business rules, read model optimized for queries.

Example:

  • Write: Order aggregate (event sourced)
  • Read: Denormalized view (user orders with product details, one query)

Common Interview Questions​

Q1: "When would you use event-driven architecture?"​

Answer:

  • Microservices: Decouple services (no direct dependencies)
  • Async workflows: Order processing (payment, inventory, shipping)
  • Scalability: Scale services independently
  • Audit trail: Financial systems (event sourcing)

Q2: "Event sourcing vs traditional CRUD?"​

Answer:

  • CRUD: Store current state (simple, but lose history)
  • Event sourcing: Store events (audit trail, replay, but complex)
  • Use event sourcing when: Need audit, time travel, or complex domain logic

Q3: "What is CQRS and why use it?"​

Answer:

  • CQRS: Separate write (commands) and read (queries) models
  • Why: Optimize each independently (normalize writes, denormalize reads)
  • Use when: Complex queries vs simple writes, or event sourcing

Quick Reference​

Event-driven: Async, decoupled (message queue/Kafka)
Event sourcing: Store events, rebuild state
CQRS: Separate read/write models
Benefits: Scalability, decoupling, audit trail

Next: Data Replication.