Almost every system you will design in this course has the same basic shape: lots of clients talking to a smaller number of servers.
Two roles, one conversation
A client is whatever starts the conversation. It's the app on your phone, a browser tab, or even another program. A client asks.
A server is a program that waits for requests and answers them. It answers. It usually lives on a machine in a data center, running all day, and it talks to the things clients shouldn't touch directly, like the database.
The words describe a role, not a type of computer. Your laptop is a client when it loads a web page, and the server that answered it may itself act as a client when it calls a payment provider.
The trip of one request
When you tap "Like":
- Your app builds a request: "user 42 likes photo 9001".
- It finds the server. A name like
api.example.comis turned into an address (that's DNS, in the next unit). - The request travels over the network to that address.
- The server checks it: are you logged in? Does the photo exist? Have you already liked it?
- The server updates the database and builds a response: "OK, the photo now has 1,204 likes".
- The response travels back, and your app turns the heart red.
Each step takes time. Steps 3 and 6 (the network) are often the slowest part, which is why latency will come up again and again in this course.
Why keep the important stuff on the server?
Putting data and rules on the server has big benefits:
- One source of truth. Everyone sees the same like count because there's one place that keeps it.
- Trust. Code on your phone can be modified by you; code on the server can't. So the server is where we check permissions and validate input.
- Easy updates. Fix a bug on the server and every client gets the fix instantly.
And one big risk:
- The server becomes a bottleneck and a single point of failure. If it's slow, everyone is slow. If it's down, nobody can like anything.
Most of system design is the art of keeping those benefits while removing that risk: more servers, load balancers, caches, replicas. That's the rest of this course.
Key idea: clients ask, servers answer, and the server is where truth and trust live. The rest of system design is about keeping that server fast and alive when millions of clients ask at once.