← Lessons

quiz vs the machine

Gold1430

System Design

The Event Driven Microservices

Services react to events on a broker instead of calling each other.

5 min read · core · beat Gold to climb

From calls to events

In a request driven style, services call each other directly, so the caller waits and knows every consumer. In an event driven style, a service publishes an event to a broker and moves on. Interested services subscribe.

What an event is

An event is a fact about something that happened, such as OrderPlaced. It is published once and read by any number of consumers.

Benefits

  • Loose coupling: the publisher does not know its consumers.
  • Resilience: if a consumer is down, events wait in the broker.
  • Extensibility: new consumers subscribe without changing the publisher.

Costs

  • Flows are asynchronous, so end to end state is eventually consistent.
  • Debugging is harder, since logic spans many reactions.
  • You must handle duplicate and out of order events idempotently.

Key idea

Event driven microservices publish facts to a broker for any consumer to react to, gaining loose coupling and resilience at the cost of async, eventually consistent flows.

Check yourself

Answer to earn rating on the learn ladder.

1. What is the main coupling benefit of event driven design?

2. Why must event consumers be idempotent?