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
Tip: the highlighter is on - just select any text below to mark it. Use the highlighter button up top to change color or turn it off, saved just for you on this device.
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.'"
Why must a server always validate data coming from a client, even data that looks well-formed?