Event-Driven Architecture: The Complete Guide#

Every major system — Uber, Netflix, Stripe, LinkedIn — runs on events. When a user places an order, that's an event. When a payment succeeds, that's an event. When a driver accepts a ride, that's an event.

Event-driven architecture (EDA) is how you build systems that react to things happening instead of waiting to be asked.

Request-Driven vs Event-Driven#

Request-driven (synchronous):

User → API → Order Service → Payment Service → Inventory Service → Email Service
                                                     ↑ waiting... waiting... waiting...

Each service calls the next and waits. If Email Service is slow, the entire chain is slow.

Event-driven (asynchronous):

User → API → Order Service → publishes "OrderCreated" event
                                  ↓
                           Message Broker (Kafka)
                           ↓         ↓         ↓
                    Payment     Inventory    Email
                    Service      Service    Service

Order Service publishes an event and returns immediately. Downstream services process independently.

Core Patterns#

1. Event Notification#

The simplest pattern. A service publishes a lightweight event; others react if they care.

{
  "type": "order.created",
  "data": { "orderId": "abc123", "userId": "user456" }
}

Consumers fetch full details from the source if needed. Low coupling, but requires additional API calls.

2. Event-Carried State Transfer#

The event contains all the data consumers need — no callbacks required.

{
  "type": "order.created",
  "data": {
    "orderId": "abc123",
    "userId": "user456",
    "items": [{ "productId": "p1", "quantity": 2, "price": 29.99 }],
    "total": 59.98,
    "shippingAddress": { "city": "SF", "zip": "94105" }
  }
}

Consumers are self-sufficient but coupled to the event schema.

3. Event Sourcing#

Instead of storing current state, store the sequence of events that led to it.

Event Log:
1. AccountCreated { id: "acc1", name: "Alice" }
2. MoneyDeposited { id: "acc1", amount: 1000 }
3. MoneyWithdrawn { id: "acc1", amount: 200 }
4. MoneyDeposited { id: "acc1", amount: 500 }

Current State: balance = 1000 - 200 + 500 = $1300

Benefits: Complete audit trail, time travel (replay to any point), no data loss. Cost: Complex queries (need projections), eventual consistency, storage growth.

4. CQRS (Command Query Responsibility Segregation)#

Separate the write model (commands) from the read model (queries):

Write Path: API → Command Handler → Event Store → publishes events
Read Path:  API → Query Handler → Read Database (optimized views)
                                       ↑
                              Event Processor (builds read models from events)

When: Reads and writes have very different patterns. Example: e-commerce catalog (millions of reads, hundreds of writes per second).

Message Brokers Compared#

When to Use Each#

• Kafka — You need event replay, high throughput, or multiple consumers per event
• RabbitMQ — You need routing, priorities, or request-reply patterns
• SQS — You want managed, simple, with no operational overhead

The Saga Pattern#

How do you handle transactions across multiple services?

Choreography — services react to each other's events (no coordinator):

Order Created → Payment Service charges card
Payment Succeeded → Inventory Service reserves items
Inventory Reserved → Shipping Service creates shipment

Orchestration — a saga coordinator tells each service what to do:

Saga Orchestrator:
  1. Tell Payment: charge card
  2. If success → Tell Inventory: reserve items
  3. If success → Tell Shipping: create shipment
  4. If any fails → compensate (refund, unreserve)

When NOT to Use Events#

Events add complexity. Don't use them when:

1. Simple CRUD — A monolith with direct function calls is simpler
2. Strong consistency required — Events are eventually consistent
3. Small team — The operational overhead isn't worth it for < 5 engineers
4. Request-response fits — If the caller needs an immediate answer, use sync
5. Debugging matters more than decoupling — Distributed tracing is hard

Architecture Examples#

E-Commerce Order Flow#

Web App → API Gateway → Order Service → Kafka
                                          ↓
                          Payment Service (charges card)
                          Inventory Service (reserves stock)
                          Email Service (sends confirmation)
                          Analytics Service (tracks conversion)

Generate this architecture →

Real-Time Analytics Pipeline#

App Events → Kafka → Stream Processor (Flink/Spark)
                          ↓
                   ClickHouse (analytics DB)
                          ↓
                   Grafana Dashboard

IoT Data Pipeline#

Sensors → MQTT Broker → Kafka → Stream Processor
                                    ↓        ↓
                              Time-Series DB  Alert Service
                              (InfluxDB)      (PagerDuty)

Getting Started#

1. Start with a queue — SQS or RabbitMQ for simple async tasks
2. Graduate to Kafka when you need replay, multiple consumers, or event sourcing
3. Add CQRS when read and write patterns diverge significantly
4. Implement sagas when transactions span multiple services
5. Always add dead-letter queues — events that fail processing need a place to go

Summary#

---

Design your event-driven architecture at codelit.io — generate interactive diagrams, run performance audits, and export as Kafka + infrastructure code.