Client and server: who asks and who answers

On os:1 you followed one program on one machine: it gets a slice of the CPU, it owns some pages of memory, it can be paused and resumed. On networking:1 you followed one request across the planet: it finds a host, it opens a TCP connection, it comes back as a response. Architecture starts where those two meet. The moment your program talks to a program on another machine, you are not writing one program any more. You are drawing a line between two of them, and almost every decision that follows depends on where you draw that line.

The client is the program that starts the conversation. It has a screen, a user, and no idea what the right answer is. The server is the program that waits for conversations, holds the data, and decides what to do with each request. That is the whole definition, and it says nothing about size: a phone can be a client, but the same phone can run a server; a laptop is a server while it hosts a game for your friends. What makes something a server is that it answers requests it did not start, and that other people's requests arrive whether it is ready or not.

GET /orders/77 HTTP/1.1
Host: shop.example
Authorization: Bearer eyJhbGciOi...


HTTP/1.1 200 OK
Content-Type: application/json

{"id": 77, "total": 12.90, "status": "paid"}

Here is the rule that decides almost everything: the client is not yours. It runs on somebody else's machine, on a network you do not control, and its code can be read and changed in a browser's developer tools in about ten seconds. So the server must never believe a client. "I am user 5" is a claim, not a fact. The server has to check it against something the client cannot forge, usually a token that was signed on the server. A price sent by the browser is a suggestion that must be recomputed from the database, never a number to charge.

A server that keeps nothing between requests is called stateless. It gets a request, produces an answer, and forgets the request ever happened. That sounds like a downgrade, but it is the reason a single server can handle a million people: nothing about you is pinned to that particular machine, so your next request can go to any of twenty identical ones. Anything that must survive between requests — a shopping cart, a login — is stored somewhere shared: a database, a cache, or inside a signed token the client carries around. This is the same idea you saw with HTTP on networking:1, now applied as an architectural choice.