Event-Driven Architecture

Pradeep P
3 days ago
3 min read

Series: Modern System Design · Layer 2 — Communication

Layer 2 · Post 7 of 10

Layer 2 — Communication · Post 22 of 88

In an event-driven system, services react to facts that already happened instead of calling each other for every next step.

What you'll learn

Events vs commands
What "event-driven" buys you (and the mess it can create)
A small design you can draw in an interview

The idea in one minute

Command: "Please do this" (ChargeCard, SendEmail). The sender wants an outcome.

Event: "This happened" (CardCharged, EmailSent). The sender states a fact. Others may react.

Event-driven architecture (EDA) organizes a system around events. Services publish facts. Other services subscribe and update their own data or trigger their own work. There is no central orchestrator for every feature — or there is one on purpose (sagas, Layer 4).

Queues, Kafka, and pub/sub are transports. EDA is the habit of speaking in facts.

Why it matters

Synchronous chains do not scale as organizations. Every new product wants a hook in checkout. Checkout becomes a switchboard.

EDA says: checkout publishes OrderPlaced. Anyone who cares listens. Checkout stays small. You pay with asynchrony, eventual views, and harder debugging (a request id should flow through every event — Layer 5 tracing).

How it works

Notification vs event-carried state

Thin event: { "orderId": "9" } — listeners fetch the rest. Simple, chatty, can race (the fetch sees a later state).
Fat event: the payload includes what listeners need. More coupling to the schema, fewer extra reads.

Most systems mix: ids plus a few fields, source of truth still in a DB.

Choreography vs orchestration

Choreography: each service reacts. OrderPlaced → inventory reserves → StockReserved → payments capture. No conductor. Elegant until a step fails in the middle (sagas).
Orchestration: a workflow service tells others what to do, waits, decides. Easier to see the flow; the orchestrator can become a hotspot.

Consistency

Listeners' databases lag. The UI might show "processing." That is eventual consistency (Layer 4) showing up as product copy.

A simple example

Ride-sharing:

TripRequested → matching service
DriverAssigned → notify rider and driver
TripStarted / TripEnded → billing, receipts, fraud

The rider app does not call billing. Billing listens to TripEnded. If billing is down, trips still end; bills catch up.

Common mistakes

Commands dressed as events. PleaseChargeCustomer on an "event bus" is still a command. You hid an RPC.

No event catalog. If nobody can list the events, you do not have an architecture. You have a pile of topics.

Distributed transaction via hope. "We'll publish both events." One publish can fail. Outbox pattern / CDC (Layer 4) exists for this.

Debugging by feeling. You need correlation ids from the first click through every message.

How this shows up in real systems

Shopify, Netflix, banks: event buses between domains.
Serverless: EventBridge, Pub/Sub as the glue.
CQRS / event sourcing: EDA taken into the data model (Layer 4).

Interview: name 3 events, who publishes, who consumes, what happens if a consumer is down.

Recap

EDA coordinates via facts, not via a web of sync calls.
You gain decoupling and lose a single timeline. Make that a product choice.
Transports (queue / log / pubsub) are tools; the event names are the design.

Some interactions are still live and two-way. That is WebSockets.

Series: Modern System Design · Layer 2 — Communication

Layer 2 · Post 7 of 10

← Previous: Pub/Sub → Next: WebSockets