Event-Driven Architecture

The big idea

At a wedding, the photographer doesn't phone the caterer, the band and the florist when the couple arrives. Someone announces "The couple has arrived!", and everyone who cares reacts in their own way: the band starts playing, the caterer serves drinks, the photographer takes pictures.

In an event-driven architecture (EDA), components announce facts ("OrderPlaced") instead of calling each other ("please reserve stock, then charge the card, then email the customer"). Whoever is interested reacts.

Event-driven: one producer publishes a fact; many consumers react independently

Request-driven vs event-driven

Anatomy

Two topologies

Broker topology (choreography)

No central brain. Each service reacts to events and publishes its own.

✅ Highly decoupled and scalable. ❌ Hard to see or change the overall flow; error handling is spread out.

Mediator topology (orchestration)

A mediator (orchestrator) receives the initial event and directs the steps.

✅ The flow and error handling are in one place. ❌ The mediator is extra coupling and a potential bottleneck.

The four event patterns (Martin Fowler)

"Event-driven" means several different things. Knowing which one you mean avoids confusion:

Designing good events

{
  "eventId": "0b8c4f0e-6a57-4f7e-9b3d-2f1d1c9a7e11",
  "type": "shop.ordering.OrderPlaced",
  "version": 2,
  "occurredAt": "2026-09-28T10:15:00Z",
  "source": "ordering-service",
  "correlationId": "req-7f3c",
  "data": {
    "orderId": "o42",
    "customerId": "c7",
    "totalCents": 8997,
    "currency": "EUR",
    "lines": [{ "sku": "KB-1", "quantity": 1 }]
  }
}

The hard parts (be honest)

(The Kafka and Microservices topics cover delivery guarantees, the outbox, sagas and CQRS in depth.)

EDA inside a single application

Event-driven isn't only for microservices. Inside a modular monolith, modules can communicate with in-process domain events, keeping modules decoupled without any broker:

// A tiny in-process event bus
type Handler<E> = (event: E) => Promise<void>;
class EventBus {
  private handlers = new Map<string, Handler<any>[]>();
  on<E extends { type: string }>(type: E["type"], handler: Handler<E>) {
    this.handlers.set(type, [...(this.handlers.get(type) ?? []), handler]);
  }
  async publish(event: { type: string }) {
    await Promise.all((this.handlers.get(event.type) ?? []).map((h) => h(event)));
  }
}

bus.on("OrderPlaced", (e) => loyalty.awardPoints(e.customerId, e.totalCents)); // loyalty module
bus.on("OrderPlaced", (e) => email.sendConfirmation(e.orderId));               // notifications module

Later, if a module becomes a separate service, swap the in-process bus for Kafka or RabbitMQ; the handlers barely change.

When to use it

✅ Many independent reactions to the same business facts, spiky traffic that needs buffering, integrating many systems, real-time processing, audit trails.

❌ Simple request/response flows where the user needs an immediate answer, small systems where the added complexity isn't earned, and workflows needing strict, immediate consistency.

Key takeaways

• Components publish facts and react to facts instead of calling each other directly.
• Broker topology (choreography) maximises decoupling; mediator topology (orchestration) makes flows explicit.
• Know which pattern you mean: notification, event-carried state transfer, event sourcing, or CQRS.
• Design events as versioned public contracts with IDs and correlation IDs.
• Plan for eventual consistency, duplicates, ordering and debugging from day one.