Clients, Servers, and the Request-Response Cycle
You'll learn to
- -Explain the roles of a client and a server
- -Trace a request from a button click to a rendered response
- -Understand why this simple model underlies every system in this course
Every system in this course (no matter how many components it eventually grows) starts from the same two actors: a client that wants something, and a server that provides it. Understanding this relationship precisely is worth doing slowly, because every later chapter just adds more pieces between the two.
What a Client Is
A client is whatever initiates a request: a web browser, a mobile app, another server calling an API, even a script running on a schedule. Clients are, by design, untrusted. A server can never assume the data coming from a client is well-formed, authorized, or honest; it always validates.
What a Server Is
A server is a program listening for requests and returning responses. The word "server" describes a role, not a specific piece of hardware: a single machine can run many servers, and one logical "server" in a system design might actually be dozens of physical machines behind the scenes (you will see exactly how in the next module).
The simplest possible system: one client, one server.
The Request-Response Cycle
- -The client builds a request: what resource it wants, and any data it's sending.
- -The request travels over the network to the server.
- -The server parses the request, runs whatever logic is needed (read a database, run a calculation), and builds a response.
- -The response travels back to the client.
- -The client renders or acts on the response.
This is a synchronous, one-shot exchange: the client asks a question and waits for the answer. Later in this course (Real-Time Systems) you'll see architectures where the server can push data to the client without being asked first.
What happens if the server crashes halfway through handling a request?
"The client just retries the request." This is true but incomplete, since it skips the actual risk.
"Whether a retry is even safe depends on idempotency. If the request was 'transfer $50' and the server crashed after debiting but before confirming, a naive retry double-charges. That's exactly why idempotency keys exist (covered later in this course), and why timeouts need a defined, tested behavior, not just 'it'll probably be fine.'"