Client-Server Model

A client is any program that initiates a request: your web browser, a phone app, a command-line tool like curl, or even another server calling an API. A server is a program that waits for requests, does some work, and replies. The defining rule is that the client always speaks first and the server never starts the conversation on its own.

This split lets one server handle thousands of clients at once, and lets a client be a thin, simple program that does not need to store all the data or run all the heavy logic. The browser on your laptop does not contain Gmail's inbox; it just asks Google's servers for it and renders what comes back.

It contrasts with peer-to-peer, where every machine is both a client and a server and there is no central authority. BitTorrent and the original Skype were peer-to-peer. Almost everything else you use daily, from Amazon to your banking app, is client-server.

Say you open systemdesign.academy. Your browser (the client) first resolves the domain name to an IP address through DNS, then opens a TCP connection to that address on port 443 and runs a TLS handshake to encrypt the channel. Only then does it send an HTTP request like GET / with headers describing what it wants.

The server receives that request, often through a load balancer that picks one of many backend machines. The chosen server runs application code, maybe queries a database like PostgreSQL, builds an HTML or JSON response, and sends it back down the same connection with a status code such as 200 OK or 404 Not Found.

Each request is independent. Plain HTTP is stateless, meaning the server does not remember you between requests by default. To recognize a logged-in user, the server hands the client a session cookie or a token that the client attaches to every later request. That is how the model fakes continuity on top of one-off message exchanges.

The client-server model is the default for almost any system where data must be shared, secured, or kept consistent across many users. Centralizing data on a server means you control access, run backups, push updates in one place, and keep a single source of truth. That is why every SaaS product, online store, and multiplayer backend uses it.

The trade-offs are real. The server is a central point of failure: if it goes down, every client is stuck, which is why production systems run many server replicas behind a load balancer. The server is also a scaling bottleneck, since one machine can only handle so many simultaneous connections before you must add more capacity or shard the load.

There is also latency baked in. Every interaction is a network round trip, so a user in Sydney talking to a server in Virginia pays the speed-of-light cost on every request. Engineers fight this with CDNs, caching, and edge servers placed closer to users, but the underlying request-response shape never changes.