The most fundamental relationship in every system: an asker, an answerer, and the gulf between them. Most engineers use these words without ever questioning why the relationship is shaped this way — let's fix that, and watch what happens when too many askers show up at once.
Imagine a small diner at lunch hour. Hungry customers walk in and place orders. The kitchen reads each ticket, cooks the food, slides it back out. The customers eat; the kitchen never sits down. This entire dance — the asymmetry, the queue, the inevitable moment when too many orders pile up — is exactly the shape of every client-server system on the internet.
The customers wait. The kitchen works. The kitchen never walks over to a table unprompted to say "hey, do you want anything?" That would be weird. That would also be exactly what makes client-server an asymmetric relationship — and that asymmetry is doing more work than you might think.
Client and server aren't just two computers. They're two distinct roles with different responsibilities, different lifecycles, and very different problems. Mixing them up — even in your mental model — leads to bad design decisions later.
This isn't a technical limitation — it's a design choice that scales beautifully. Because the server is passive, it can serve anyone who shows up. It doesn't need to know in advance who its clients will be. A web server in a data center has no idea your phone exists until your phone introduces itself. That property — "servers don't need to know about clients in advance" — is what allows the internet to be the internet.
The word "client" makes people picture Chrome. But once you internalize the role — "anything that initiates a request" — it expands to cover most of the software in the world. Click any card to see real-world examples.
Chrome, Safari, Firefox. The most familiar client — it loads HTML, runs JavaScript, and makes HTTP requests on your behalf as you click around.
iOS and Android apps make API calls constantly — to fetch posts, send messages, upload photos, check notifications. They use HTTP under the hood, just like a browser.
Smart thermostats, fridges, watches, cars. They have tiny computers, weak network, and they phone home constantly to sync state and check for updates.
Here's the trick: a server, when it calls another server, is acting as a client. This is the foundation of microservices, where everything calls everything.
The key insight: "client" and "server" are roles, not identities. A single piece of software can be both, just not in the same conversation. Once that clicks, microservices stop feeling magical.
Crank up the number of clients below and watch the server's queue grow, its response time degrade, and — if you push hard enough — its capacity collapse. Every backend engineer has felt this curve in production at least once. Feel it here first, in safety.
A handful of clients, and the server breezes through. Requests in, responses out, no queue ever builds. This is the happy path — but it's the easy one.
Each dot is a request. Blue = in flight. Yellow = waiting in queue. Red = rejected. The server can only handle ~5 requests/sec. Push past that and physics wins.
Now that you've internalized "client speaks first, server replies" — let's gently complicate it. Sometimes the client wants to know about events the moment they happen, not the next time it asks. The way you handle this question shapes the entire architecture.
Notice: in every case, the client still has to open the door first. You can't have a server randomly knocking on a phone that hasn't ever connected to it. Even "push" is really "pull-with-extra-steps". That asymmetry never fully goes away. We'll go deep on WebSockets and SSE in Module 14 — for now, just remember that the question "who initiates updates?" is one of the most important design choices you'll ever make.
Module 01 gave you the basics. Here's what the client-server world adds. Get fluent with these — they show up in every system design conversation you'll ever have.
80 for HTTP, 443 for HTTPS, 5432 for Postgres.Quick test of the client-server intuition you've built. Pick an answer; you'll get instant feedback.
You've got the asymmetry locked in. Time to look at the protocol that powers it.
The next 18 modules treat these as table stakes. Lock them in.
Servers wait. They're generous, patient, and slightly oblivious. The whole internet works because of this rule.
The same piece of software can be a client in one conversation and a server in another. Microservices live here.
Adding clients to one server isn't free. The queue grows, latency rises, and eventually it all collapses. This is why we scale.