Clients and servers

Who asks, who answers.

Nearly every system you will design is built on one simple pattern: a client asks, a server answers. The client is whatever the user touches: a phone app, a browser, even another program. The server is a program running on a machine somewhere that holds the logic and data the client does not. In a food-delivery app, the phone shows restaurants; the server knows which restaurants are open and which orders exist.

Follow a single tap on Show restaurants. The phone first needs an address, so it asks DNS, the internet's phone book, to turn a name into an IP address. Then it opens a connection and sends an HTTP request over it. The server runs code, perhaps asking the database for rows, and builds a response. The client draws the result. Each hop costs time: a few milliseconds locally, over a hundred if the server is on another continent.

A key property of the usual web design is that the server is stateless between requests: it does not remember who you are from one request to the next unless the request itself carries that information. This sounds like a limitation but is a gift. Any one of ten identical servers can answer any request, so you can add more servers when traffic rises, and replace a crashed one without anyone losing their place. State lives in the database, not in the server's memory.

Why not let the client talk to the database directly? Because the client is in the hands of users and cannot be trusted. Anyone can read what an app sends, edit it, and replay it. The server is the place where rules are enforced: who may see which order, how much a delivery costs, whether a coupon is valid. Anything checked only on the client is only a suggestion.

GET /restaurants?city=pune HTTP/1.1
Host: api.example.com
Accept: application/json

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

[{"id": 12, "name": "Spice Route", "open": true}]