Event-Driven Architecture

Event-Driven Architecture (EDA) structures systems around the production, detection, and reaction to domain events — immutable facts about what happened (OrderPlaced, PaymentProcessed, ShipmentDispatched). EDA enables loose coupling: services react to events without knowing who produced them or who else is reacting. The two coordination models — choreography (services react autonomously to events) and orchestration (a central coordinator commands each step) — each have distinct trade-offs in visibility, coupling, and error handling.

Key Points

• Domain events are past-tense, immutable facts: OrderPlaced (not PlaceOrder); they contain all data needed for consumers to react without additional queries — include aggregate ID, version, timestamp, and causation ID.
• Choreography: each service subscribes to events and publishes new events in response; highly decoupled but distributed business logic is hard to visualize and debug — use distributed tracing to reconstruct flow.
• Orchestration: a central coordinator (saga orchestrator, workflow engine like Temporal/Step Functions) calls each service in sequence; business logic is centralized and visible; the coordinator becomes a potential bottleneck.
• Event schema evolution: use envelope pattern (eventType, schemaVersion, payload); support backward-compatible changes (add optional fields); use Schema Registry to enforce compatibility.
• Event sourcing (complementary pattern): store all state changes as events in an append-only event store; derive current state by replaying events — provides complete audit trail and enables temporal queries.
• Event catalog / service map: document all events, their schemas, and publisher/subscriber relationships — critical for impact analysis when changing an event schema (who will break?).
• EDA challenges: eventual consistency between services, distributed debugging (use correlation/causation IDs), event ordering guarantees, idempotent consumers (events may be delivered multiple times).
• CQRS + EDA: Command side writes events to the event store; Query side builds read models by consuming events — each projection is independently optimized for its specific query pattern.