Event-Driven Communication

Analogy categoryAnalogies

Reacting to Events Instead of Requesting Data

Event-driven communication inverts the request-response mental model: instead of a service asking another service for data or telling it to do something, a service publishes a fact about something that already happened — an event, like OrderPlaced or InventoryDepleted — and any number of interested services subscribe and react independently. The publisher has no knowledge of who is listening or what they will do; it simply broadcasts. This decouples services not just in time (as asynchronous messaging does) but also in knowledge: the order service doesn't need to know that a shipping service, a loyalty-points service, and an analytics service all care about OrderPlaced events.

🏏

Cricket analogy: A stadium's PA system announcing 'Six!' is like publishing an event: the announcer doesn't know or care whether the scoreboard operator, the broadcast director, or the crowd's Mexican wave all react to it independently.

Choreography vs Orchestration

Event-driven systems tend toward choreography, where each service knows its own reactions to events and the overall workflow emerges from many independent, decentralized decisions, rather than orchestration, where a central coordinator explicitly calls each participant in sequence. Choreography scales well organizationally because teams can add new event subscribers without touching the publisher's code, but it makes the end-to-end flow harder to see at a glance, since there is no single place that lists 'when an order is placed, do A, then B, then C.' Distributed tracing and event catalogs become essential tools for regaining that visibility.

🏏

Cricket analogy: Choreography is like a fielding side where every player independently knows their role when the ball is hit their direction, versus orchestration being a captain shouting individual instructions for every single ball.

Event Schemas and Versioning

Because many independent consumers depend on an event's shape, event schemas need the same discipline as REST or gRPC contracts, if not more, since a publisher often cannot even enumerate all its consumers. Best practice is to treat events as append-only facts (never mutate a published event) and to evolve schemas additively, using a schema registry to enforce compatibility rules before a producer is allowed to publish a breaking change. Including an event type and version in the payload, like order.placed.v2, lets consumers explicitly opt into new fields while old consumers keep working against the fields they already understand.

🏏

Cricket analogy: Treating events as immutable, append-only facts is like an official scorecard entry that's never erased once recorded, only ever appended to, so the historical record of the innings stays trustworthy.

json

{
  "eventType": "order.placed.v2",
  "eventId": "6f1c9e2a-8b3d-4a2f-9c1e-7d5b6a4f3e21",
  "occurredAt": "2026-07-10T14:32:05Z",
  "producer": "orders-service",
  "data": {
    "orderId": 42,
    "customerId": 17,
    "total": 59.98,
    "currency": "USD",
    "loyaltyTier": "gold"
  }
}

// A subscribing shipping-service handler
function onOrderPlaced(event) {
  if (event.eventType !== 'order.placed.v2') return; // ignore unknown/older types
  createShipmentDraft(event.data.orderId, event.data.customerId);
}

Event-driven choreography can produce workflows that are difficult to debug because there is no single call stack to inspect; a failure three services downstream from the original event can be hard to trace back to its cause without correlation IDs and centralized distributed tracing.

Many teams maintain an event catalog — a living document or schema registry listing every event type, its owning service, its schema, and its known consumers — specifically to counteract the loss of visibility that choreography introduces.

Event-driven communication has a publisher broadcast a fact about something that happened, with subscribers reacting independently.
This decouples services in both time and knowledge: the publisher doesn't know who is listening or what they'll do.
Choreography lets workflows emerge from independent service decisions; orchestration uses a central coordinator to sequence steps.
Choreography scales organizationally but reduces end-to-end visibility, requiring distributed tracing and event catalogs.
Events should be treated as immutable, append-only facts, never mutated after publication.
Event schemas should evolve additively and be versioned (e.g., order.placed.v2) to protect existing consumers.
A schema registry helps enforce backward compatibility before a producer is allowed to publish a breaking change.