Stop 15 · Message Queues & Event-Driven ArchitectureTopics · 6/8

Event-Driven Architecture

In short

Instead of services calling each other in a long chain, each one announces what happened and others react. That's event-driven architecture, and it's how big apps stay flexible.

Designing a system around services reacting to events (things that happened) rather than direct calls to each other — improving decoupling but adding complexity in tracing and consistency.

The blob beats a dhol while a cooking pot steams, a camera flashes and marigold garlands hang nearby.

Think of it like this

The dhol at a wedding

When the dhol starts at the baraat, nobody sends individual messages. The cooks start the tandoor, the photographer starts clicking and the family lifts the garlands. Each one heard the same event and knows their own job. Add a band next year and the dhol player changes nothing.

Watch it happen

Reacting to order.placed

Order svc

Event bus

Inventory

Email svc

order.placed #4821

1/5The order is saved, then the order service publishes a fact: this order was placed.

The big ideas

What you need to know

Events are past facts

Name them in past tense: order.placed, payment.failed. A command (send email) asks; an event (user signed up) tells.

Loose coupling

Services only share event formats. Inventory can be down for a minute and catch up later without breaking checkout.

Eventually consistent

For a short while, the order is placed but stock isn't reserved yet. Design screens and logic for that gap.

Trace with ids

Put a correlation id on every event, so you can follow one order through five services in the logs.

See it in code

Walk through the code

json

1{2  "id": "evt_01J9Z6K2Q8",3  "type": "order.placed",4  "occurredAt": "2026-03-14T10:15:00Z",5  "version": 1,6  "data": {7    "orderId": "ord_4821",8    "userId": "usr_77",9    "total": 1299,10    "currency": "INR"11  }12}

1/3A unique id lets consumers skip duplicates. The type says what happened, in past tense.

A good event envelope: unique id, type, time, schema version and a small data payload. Treat the format like a public API; others depend on it.

Save yourself the pain

Common mistakes

Oops

Publishing the event before the database save commits.

Do this instead

Save first, or use an outbox table that's published after commit. Otherwise you announce orders that don't exist.

Oops

Turning every function call into an event.

Do this instead

Use events across service boundaries where loose coupling helps. Inside one service, a normal function call is fine.

Your mission

Map one checkout as events

~25 min

Quick check

Which of these is best named as an event?

Go deeper

1Redesign a simple feature (order placed → send email → update inventory) as a sequence of events.
2Learn the trade-off: event-driven systems are more decoupled but harder to trace and debug.
3Understand eventual consistency as a consequence of asynchronous, event-driven flows.