Event-Driven Architecture

Overview

Event-driven architecture (EDA) uses events to decouple producers from consumers. A producer emits a fact, and one or more consumers react asynchronously.

Event Flow Model

sequenceDiagram
    participant OrderService
    participant Broker
    participant InventoryService
    participant NotificationService

    OrderService->>Broker: OrderCreated
    Broker->>InventoryService: OrderCreated
    Broker->>NotificationService: OrderCreated

Production Example

A retail platform publishes order lifecycle events through a broker such as Kafka.

{
  "eventType": "OrderCreated",
  "eventId": "evt-90af",
  "orderId": "ord-1452",
  "occurredAt": "2026-09-06T10:30:00Z",
  "customerId": "cust-2009",
  "items": 3
}

Inventory and notification services subscribe independently. New consumers can be added without changing the producer.

Reliability Patterns

• Idempotent consumers for duplicate delivery handling
• Dead-letter queues for poison messages
• Retry policies with exponential backoff
• Schema registry for event contract evolution

Common Pitfalls

• Missing event versioning strategy
• Assuming event ordering across all partitions
• Creating chatty event streams with low business value

Key Takeaways

• EDA improves decoupling and extensibility.
• Reliable event processing requires idempotency and schema governance.
• Asynchronous workflows reduce direct service dependencies.