Skip to main content

Event-Driven Architecture

Event-driven architecture is a system-wide design choice: services communicate primarily by producing and reacting to events — facts about something that already happened ("order placed," "payment failed," "user signed up") — rather than by calling each other directly and waiting for a response. This module's Asynchronous Communication lessons (Pub/Sub, Message Queues, Change Data Capture) covered the specific mechanisms; this lesson is about the architectural decision to build a whole system around them as the default way services talk to each other.

The shift: from asking to announcing​

A request-driven system is built around direct calls: service A calls service B, and waits for B's response before continuing — the Client-Server model, applied service-to-service. An event-driven system inverts this: service A finishes its own work, announces what happened by publishing an event, and moves on immediately — it never calls B directly, doesn't wait for B, and often doesn't even know B exists.

System Design Lab

Why a whole architecture, not just one integration​

Using Pub/Sub for one notification here or there is a tactical choice. Committing to event-driven architecture as the system's default shape is a different, bigger decision: it means most services publish what changed rather than calling their consumers, most cross-service consistency is handled through eventually-processed events rather than synchronous multi-service transactions, and new functionality is added by subscribing a new consumer to existing events rather than modifying the producer to call one more downstream service. This is precisely the property Pub/Sub named as its core value, applied at the scale of an entire system's integration style: producers never need to change when a new consumer is added.

What this buys a Microservices Architecture specifically​

Recall the hard problem microservices leaves open: once each service owns its own database, a single business operation that used to be one ACID transaction now spans multiple services with no shared transaction to wrap it. Event-driven architecture is the standard answer — instead of the order service directly, synchronously calling the inventory and shipping services within one request (tightly coupling all three, and failing the whole operation if any one of them is briefly unavailable), it publishes "order placed" once and lets inventory and shipping each react independently, on their own schedule, tolerating each other's brief unavailability entirely. The cost, made explicit in Change Data Capture, is that this consistency is now eventual rather than immediate — every consumer catches up a little after the fact, not atomically alongside the original write.

Choreography vs. orchestration​

Event-driven systems tend to fall into one of two coordination styles, and naming the distinction is a strong signal of real familiarity with the pattern:

  • Choreography — there's no central coordinator; each service reacts to events and publishes its own events in turn, and the overall flow emerges from many independent, local reactions. Highly decoupled, but the end-to-end flow of a business process isn't written down anywhere in one place — it has to be inferred from what every service does.
  • Orchestration — a central coordinator explicitly calls each step in sequence (which may itself be event-driven under the hood) and tracks the overall process's state. Easier to see and reason about the whole flow in one place, at the cost of that coordinator becoming a dependency every step now has.

Neither is strictly better — choreography scales better organizationally (no one service needs to know the whole process), while orchestration is easier to debug and modify when the process itself has complex branching logic.

Why this matters in an interview​

Proposing event-driven architecture should come with the specific problem it's solving — usually "these services need to stay eventually consistent without a distributed transaction" or "new consumers need to be addable without modifying the producer." It's also worth being ready to name the real cost: eventual rather than immediate consistency, and a system-wide flow that's genuinely harder to trace end-to-end than a sequence of direct calls, which is exactly why Distributed Tracing becomes close to mandatory once an architecture goes fully event-driven.

Choreography vs. orchestration: pros and cons​

Choreography

  • No central coordinator, so no single dependency every step relies on
  • Services can be added or changed without touching a shared coordination layer
  • Scales better across independent teams — no one owns the whole process

Orchestration

  • The coordinator becomes a dependency every step in the process now relies on
  • A failure or bottleneck in the coordinator can stall the entire process
  • Adding a new step means modifying the shared coordination logic directly

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.