Introduction

1. What This Module Covers

Every system design diagram contains boxes connected by arrows. The boxes represent services such as an API, a database, or an email sender, while the arrows show data moving between them.

Engineers often concentrate on the boxes, but this module examines the arrows because each arrow represents a design decision.

Whenever service A sends information to service B, you must choose how that message travels. This choice determines three important behaviors:

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

Careless choices can cause production outages, and the lessons in this module begin with two examples. A flash sale crashed a store that had enough capacity, while a "real-time" dashboard spent most of its budget asking "anything new?" and receiving "no."

2. The Seven Patterns

3. Two Rules for the Whole Module

Rule 1: Request-response is the default. Make a direct call when the user must wait for an answer. The other six patterns address cases in which waiting is either wasteful or impossible.

Each alternative introduces costs, so it is not automatically an improvement. Less experienced engineers sometimes choose an advanced pattern when a direct call would be clearer and safer.

Rule 2: Anything that retries can deliver twice. Queues, events, and webhooks resend messages when delivery may not have succeeded. This behavior is intentional because it prevents data loss.

However, your code must accept the same message twice without repeating its effect. This property is called idempotency: performing an operation twice produces the same result as performing it once. It has its own lesson later in the course.

For now, treat duplicate delivery as normal and design for it from the beginning.

4. How to Read This Module

These lessons follow one online store through a sequence of communication decisions. The store begins with a synchronous design, which means each step waits for the previous one. A flash sale breaks that design and creates the need for a queue.

The queue succeeds, and five additional teams then need its data, which creates the need for publish-subscribe. However, the published events contain too little information, so every receiving service calls the source for details. Event-driven architecture addresses that problem.

Next, the external payment provider must send information into the store, which introduces webhooks.

That sequence runs from Request-Response through Webhooks, so read those five lessons in order when possible. The following pair, Server-Sent Events and Bidirectional Streaming, covers live data streams. Finally, the capstone combines all seven patterns in 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 describes work that should happen once, such as "resize this image." A fact records something that happened, such as "an order was placed." Jobs belong on queues, while facts are published. Confusing these two message types is the most common communication mistake.
2. At-least-once delivery. The system guarantees that it will not lose your message, although it may deliver that message more than once. See Rule 2.
3. Push vs. pull. With pull, the client repeatedly asks whether new data exists. With push, the server sends updates when they occur. Pull consumes requests, while push keeps connections open, and both approaches have a cost.
4. Synchronous vs. asynchronous. Synchronous communication makes the caller stop and wait for an answer. Asynchronous communication lets the caller hand off a message and continue.

6. Before You Start

Consider these three questions about a system you have worked on. "I don't know" is a useful starting answer because this module will give you a method for finding out.

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?

Begin with Request-Response, the shortest lesson in this module. Every later pattern changes the decision to make a direct call.