Introduction

1. What This Module Covers

Every system design diagram is made of boxes and arrows. The boxes are services: the API, the database, the email sender. The arrows show data moving between them.

Most engineers focus on the boxes. This module is about the arrows, because every arrow is a decision. When service A needs to tell service B something, you have to choose how that message travels. That one choice decides three things:

1. Does anyone have to wait for the answer?
2. What happens when B is down?
3. What happens if the message arrives twice?

Choosing carelessly causes real outages. The lessons in this module open with two of them: a flash sale that crashed a store that had plenty of capacity, and a "real-time" dashboard that spent most of its money asking "anything new?" and hearing "no."

2. The Seven Patterns

3. Two Rules for the Whole Module

Rule 1: Request-response is the default. If the user is waiting for the answer, make a direct call. The other six patterns exist for cases where waiting is wasteful or impossible. They are upgrades with costs, not automatic improvements. A common junior mistake is using an advanced pattern where a simple call was the right choice.

Rule 2: Anything that retries can deliver twice. Queues, events, and webhooks resend messages when they are not sure a delivery succeeded. This is intentional: it is how they avoid losing data. But it means your code must handle the same message arriving twice without doing the work twice. This property is called idempotency, and it has its own lesson later in the course. For now, remember: duplicates are normal, so plan for them.

4. How to Read This Module

The lessons tell one continuous story about one online store. A flash sale breaks its synchronous design, which leads to a queue. The queue works so well that five other teams want the data, which leads to publish-subscribe. The events carry too little information, so every consumer calls back for details, which leads to event-driven architecture. Then the payment provider starts calling into the store from outside, which leads to webhooks.

That story runs from Request-Response through Webhooks, so those five lessons are best read in order. The next two, Server-Sent Events and Bidirectional Streaming, are a pair about live data streams. The capstone then uses all seven patterns to design one notification system.

💡 Short on time before an interview? Request-Response, Message Queue, Publish-Subscribe, and Webhooks are the four patterns interviewers ask about most.

5. Four Terms Used Throughout

1. Job vs. fact. A job is work to do once: "resize this image." A fact is something that happened: "an order was placed." Jobs go on queues. Facts get published. Confusing the two is the most common communication mistake.
2. At-least-once delivery. The system guarantees your message will not be lost, but it may be delivered more than once. See Rule 2.
3. Push vs. pull. Pull means the client keeps asking whether there is anything new. Push means the server sends updates when they happen. Pull wastes requests; push holds connections open. Both have a cost.
4. Synchronous vs. asynchronous. Synchronous means the caller stops and waits for the answer. Asynchronous means the caller hands off the message and moves on.

6. Before You Start

Try answering these three questions for a system you have worked on. "I don't know" is a fine answer; this module exists to change it.

1. Find your slowest API call. Is a person actually waiting for its result?
2. When your code puts a message on a queue, what happens if that message is delivered twice?
3. Does anything in your product refresh on a timer? Out of every 100 refreshes, how many find something new?

Start with Request-Response. It is the shortest lesson, and every other pattern in the module is a variation on choosing not to make a direct call.