Module 01 / 20 · Phase A — Request & Response · 42 min

What is a System,
really?

Strip away the jargon. We trace one ordinary HTTP request from your laptop to a server on the other side of the planet — and back. By the end of this module, "system" stops being a buzzword and becomes a thing you can draw.

// What you'll know by the end

  • What a system actually is (and isn't)
  • The four atoms every system has
  • Every step a request takes — in order
  • Vocabulary every engineer uses daily
§ 01 — The opening question

You type six characters.
Then magic.

Right now, billions of people are doing the same thing: typing a URL, hitting Enter, and watching a page appear. We barely think about it. But between that keystroke and that page, a small miracle happens — and it's powered by hundreds of components cooperating across thousands of miles, in milliseconds, mostly invisible.

g
connecting...

So what actually happened? Let's find out — but first, we need a working definition of the thing we're trying to understand.

§ 02 — The simplest definition

A system is just
parts that cooperate

Forget the textbook. A system is any group of parts working together toward a shared goal. Your kitchen is a system. A car is a system. A flock of birds is a system.

What makes software systems special is just three things:

  • The parts are computers, programs, and the wires (or radio waves) between them.
  • The shared goal is usually moving information — taking data from one place to another, transforming it along the way.
  • The cooperation happens via messages: little structured packages of data that one part sends to another.
A system is what you draw on a whiteboard when someone asks you "how does it work?"

This is the core insight that makes everything else click. Every "complex" system you'll ever read about — Twitter, Netflix, Stripe, your bank — is just a lot of parts cooperating by sending each other messages. The complexity isn't in any single part. It's in how they're arranged.

§ 03 — The four atoms · interactive

Every system has
four atoms.

You can build any system in the world from these four things. Click any card to see how it shows up in real life. Get familiar with these names — you'll see them in every diagram for the rest of your career.

▢

Client

// the asker

The thing that wants something. Initiates a request. Could be a browser, a mobile app, a script, or another server acting as a client.

In real life: Your Chrome tab loading Gmail. The Instagram app on your phone. A weather widget on a smart watch. A Python script calling an API. They're all clients — they ask for things and wait for answers.
click to expand
▤

Server

// the answerer

The thing that answers. It listens for incoming requests, does some work, and sends back a response. Lives in a data center, runs 24/7.

In real life: A machine in a Google data center handling search queries. The thing that processes your card when you tap to pay. The chat backend that routes your WhatsApp messages. Servers don't initiate — they wait, then react.
click to expand
≈

Network

// the road

The wires, fibers, and radio waves connecting everything. Messages travel through it. It's slower and less reliable than you think.

In real life: Your home WiFi. The undersea cables crossing the Atlantic. The cell tower that turned your "Sent" into "Delivered". Networks fail. Networks lie. Half of all systems engineering is dealing with network reality.
click to expand
▥

Data Store

// the memory

Where information lives between requests. Servers handle requests; data stores remember things. Without storage, your app forgets everything when restarted.

In real life: The database holding your tweets. The S3 bucket holding your photos. The Redis cache holding your session token. Anything that survives a server restart is, somewhere, in a data store.
click to expand

That's it. Four pieces. Every diagram you'll ever see is some arrangement of these. The art is in how many of each, and how they connect.

§ 04 — One request, narrated · interactive lab

Now watch a real request
do all seven steps.

You typed systemdesigntutorial.com into a browser. Press Auto-play below and follow the request through every layer it touches. Each step shows you the actual data being passed.

REQUEST_LIFECYCLE.SIM // m.01 lab
BROWSER DNS TCP TLS REQUEST SERVER DATABASE ▢ @ ⇌ ⚿ → ▤ ▥ REQUEST: GET https://systemdesigntutorial.com/ — preparing to dispatch
STEP 1 / 7
Browser

You hit Enter. The browser parses the URL into protocol, hostname, and path. It needs to find the IP address of systemdesigntutorial.com before it can do anything.

parsed_url:
  protocol: https
  host: systemdesigntutorial.com
  path: /
§ 05 — Vocabulary you'll use forever

Eight words that
unlock every diagram.

Engineers use these terms constantly — in standups, in design docs, in interviews. Get comfortable with them now and the rest of this course will feel half as hard.

Request
/rɪˈkwɛst/
A message a client sends asking for something — typically wrapped in a protocol like HTTP. Has a method, headers, and sometimes a body.
Response
/rɪˈspɒns/
What the server sends back. Has a status code (200, 404, 500), headers, and usually a body containing the actual data.
Protocol
/ˈprəʊtəkɒl/
The rulebook two parts agree to follow when talking. HTTP is a protocol. TCP is a protocol. WebSocket is a protocol.
Endpoint
/ˈɛndpɔɪnt/
A specific URL on a server that does one thing. /api/users is an endpoint. So is /login.
Latency
/ˈleɪtənsi/
How long one request takes, end to end. Measured in milliseconds. Lower is better. 50ms feels instant; 500ms feels broken.
Throughput
/ˈθruːpʊt/
How many requests a system can handle per second. Different from latency — a system can be slow but high-throughput, or fast but low-throughput.
Payload
/ˈpeɪlɒd/
The actual content of a request or response — usually JSON. The "stuff" you care about, separate from the protocol metadata.
Stateless
/ˈsteɪtləs/
When a server doesn't remember anything between requests — every request must carry all the info it needs. Easier to scale. We'll go deep on this later.
§ 06 — Knowledge check

Five questions.
No cheating.

Before moving on, lock it in. The questions below test the concepts, not memorization. Pick an answer; you'll get instant feedback either way.

QUESTION 1 OF 5
Loading question...
Score: 0 / 5
5 / 5

Locked in.

You've got this. Time to keep climbing.

§ 07 — The recap

Three ideas to
carry forward.

Everything in the next 19 modules builds on these. If you remember nothing else from Module 01, remember these.

i

A system is parts cooperating

Not a black box. Not magic. A specific, drawable arrangement of components passing messages.

ii

Four atoms make any system

Client, server, network, data store. Every diagram is just these in different quantities and arrangements.

iii

A request takes seven steps

Browser → DNS → TCP → TLS → HTTP → Server → Database. And then all the way back. None of it is free.

↓ UP NEXT

M.02 — Client–Server,
Demystified

Now that you know what a system is, let's go deep on the most fundamental relationship in it: the asker and the answerer. Why is the asymmetry there? What does it cost?

Continue to Module 02 →