design-event-driven-system

Design Event-Driven System

Design systems where components communicate via immutable events, enabling loose coupling, auditability, and temporal decoupling.

Why This Is Best Practice

Adopted by: LinkedIn (Kafka origin), Uber, Airbnb, AWS (EventBridge), Martin Fowler's canonical patterns Impact: LinkedIn's move to event-driven with Kafka handled 7 trillion messages/day; event sourcing provides a complete audit log by construction, eliminating a common compliance requirement.

Why best: Events as first-class citizens decouple producers from consumers in time and space. Event sourcing makes the audit log the source of truth. CQRS separates read and write models, allowing each to scale and evolve independently.

Steps

1. Identify domain events — Use event storming: list all significant things that happen in the business domain (past tense: OrderPlaced, PaymentFailed).
2. Classify event types — Distinguish: domain events (business facts), integration events (cross-service), and commands (intent to act — not events).
3. Design the event schema — Include: event type, version, aggregate ID, timestamp, correlation ID, and payload. Use schema registry (Avro/Protobuf + Confluent Schema Registry) to enforce compatibility.
4. Choose event transport — Kafka for high-throughput durable streams; RabbitMQ for transient messaging; AWS EventBridge for cloud-native routing; in-process event bus for within-service.
5. Apply CQRS if read/write loads differ — Separate command handlers (write side) from query models (read side); project events into optimized read stores.
6. Handle eventual consistency — Design UIs and downstream consumers to tolerate lag; use correlation IDs to track saga progress.
7. Plan event versioning — Use upcasters or parallel event types for schema evolution; never mutate published event schemas.

Rules

• Events are immutable facts — never delete or mutate a published event.
• Include correlation and causation IDs in every event for distributed tracing.
• Consumers must be idempotent — the same event may be delivered more than once (at-least-once delivery).
• Avoid event sourcing for simple CRUD domains — the complexity cost exceeds the benefit.

Examples

Order saga (choreography):

1. OrderService publishes OrderPlaced.
2. InventoryService listens → reserves stock → publishes StockReserved.
3. PaymentService listens → charges → publishes PaymentConfirmed.
4. OrderService listens → marks order Confirmed.

No orchestrator; each service reacts to events independently.

Common Mistakes

• Event as RPC — publishing GetUserRequest as an event defeats the purpose; use synchronous calls for queries.
• Fat events with full entity state — creates implicit coupling; prefer thin events with IDs and let consumers fetch if needed, or use event carried state transfer intentionally.
• No dead-letter queue — failed events are silently dropped; always configure a DLQ.