What is system design? Client-server basics and vocabulary

Writing a function is about correctness — does this specific piece of logic do the right thing. System design is about a different set of questions: how do multiple pieces of software (a client, a server, a database, maybe several servers) work together, stay reliable when parts of it fail, and keep working as the number of users grows. It's less "what does this code do" and more "how is this whole thing put together, and what happens when something goes wrong or gets popular." Every other lesson in this domain (caching, load balancing, sharding, and the rest) is really answering one version of "what happens as this system gets bigger or something breaks."

A client is the thing making a request — a web browser, a mobile app, another program. A server is the thing that receives that request and responds to it — usually a program running on a machine somewhere, waiting for requests to arrive. Loading a webpage is your browser (client) asking a server for a page, and the server sending back the HTML. This client-server split is the starting shape almost every system in this domain builds on top of.

A client and server usually aren't on the same machine — the request travels over a network (the internet, or a private network inside a company) to reach the server, and the response travels back the same way. This round trip takes real time (latency) — even a fast connection has some unavoidable delay, and that delay grows the physically farther apart the client and server are. This is the entire reason a CDN (content delivery network) or a server placed close to users geographically can make a service feel faster: less physical distance for the request and response to travel.

Every interaction in a client-server system is some version of: the client sends a request (asking for something, or telling the server to do something), and the server sends back a response (the requested data, or a confirmation, or an error). The next lesson — HTTP and APIs — covers exactly what a request and response actually contain; for now, the important thing is the shape: one side asks, the other side answers, and everything in system design is ultimately about making that exchange fast, reliable, and correct even as more clients are asking at once.

A system that works perfectly for 10 users can fall apart at 10,000 or 10,000,000 — not because the logic is wrong, but because assumptions that were safe at small scale stop holding: a single server can't handle that much traffic alone, a database query that was instant on a small table becomes slow on a huge one, and a piece of code that worked fine sequentially causes real problems when thousands of requests hit it simultaneously. "System design" as a subject is largely the accumulated set of patterns (caching, load balancing, sharding, queues) for handling exactly these kinds of breakdowns — each one covered as its own lesson, each one solving a specific version of "this stopped working once real scale showed up."

Two words that come up constantly: availability (is the system actually responding to requests right now, as opposed to being down) and reliability (does it keep working correctly over time, not just working once). A system can be up (available) but returning wrong answers (unreliable), or it can be perfectly correct but frequently offline (reliable but not available) — real systems are designed to be both, and most of the patterns in this domain exist specifically to keep a system available and reliable even when individual pieces of it fail.