Systems · 28 min read
Client-Server
The dominant networked application pattern: clients initiate requests, servers listen and respond, and responsibilities split across an asymmetric relationship.
Why this exists
Distributed applications need a default pattern for who initiates communication and who owns durable state. The client-server model answers with asymmetry: many clients talk to services that listen, authorize, and persist.
It is not the only pattern (peer-to-peer exists), but it dominates the web, APIs, and enterprise systems because it centralizes control points: auth, data integrity, and upgrades.
Understanding the pattern clarifies why NAT hurts inbound services, why load balancers exist, and why 'the backend is down' is a different failure than 'my client bug.'
Axioms & primitives
- 01Clients initiate; servers listen and respond (in the classic pattern).
- 02Servers typically own authoritative state; clients own presentation and local cache.
- 03Scale often means many clients per service instance, plus horizontal scale-out of servers.
- 04Trust is asymmetric: servers must authenticate clients; clients must authenticate servers (TLS).
- 05Peer-to-peer flips assumptions: both sides may initiate and share roles.
- 06Middleboxes (LB, API gateway) are servers to clients and clients to upstreams.
Learning objectives
After this lesson you should be able to:
- Draw a client-server request path including DNS and TLS for a browser app.
- Contrast client-server with peer-to-peer for a file sharing scenario.
- Explain why home NATs make 'run a server on my laptop' painful.
- Locate where authorization must be enforced (hint: not only in the client UI).
- Describe what a load balancer changes and what it does not remove.
Progressive depth
Read the layers in order for a full explanation. Or open the layer you need.
Intuition
Your phone is a client. It opens connections and asks for things. Instagram's machines are servers: they listen, check credentials, and return feeds.
That asymmetry lets operators upgrade servers, enforce rules, and back up data in one place. Clients proliferate and vary; servers concentrate responsibility.
When both ends are equal peers, you gain resilience and different politics, but you lose a single control point. Most product apps choose client-server anyway.
Formal shape
Servers bind sockets and accept connections (or datagrams). Clients connect and send requests. Application protocols (HTTP, SQL wire protocols, game protocols) define message meaning.
Horizontal scaling: multiple server replicas, load balancer, shared database or sharded state. Sticky sessions are a coupling smell when avoidable.
Failure domains: client bugs, local network, DNS, TLS, edge, origin app, datastore. Debugging requires naming which role failed.
Push patterns (WebSockets, SSE, notifications) still usually begin with a client connecting to a listening server; the asymmetry remains.
Client-server roles
Click a stage to see the asymmetric pattern this page starts from: clients initiate, servers listen and respond.
Loading diagram...
Select a stage to read the boundary detail.
Worked examples
Web app: browser client; TLS to CDN/edge; origin app servers; database. Caching layers are helpers, not a different political model.
SSH: your laptop client to a listening sshd. Still client-server despite a shell feeling 'local.'
BitTorrent: peers exchange blocks; trackers/DHTs help discovery. Hybrid of P2P data plane with supportive infrastructure.
Mobile offline: client caches and queues writes; server remains authoritative on sync conflicts.
Edge cases
NAT and firewalls make inbound client-hosted servers hard; hole punching and relays reappear.
BFF (backend for frontend) patterns add servers that exist mainly to tailor APIs for one client type.
Serverless functions blur 'always listening' but preserve the request/response role.
Mutual TLS and zero-trust mesh make both sides present certificates; still often client-server at the app layer.
Mental models
Restaurant kitchen
Diners (clients) place orders; kitchen (server) cooks. Diners should not walk in and rewrite the recipe book.
Call center
Many callers, few agents. Queues, hours, and identity checks live at the center.
Library desk
Authoritative catalog and stacks sit on the server side; patrons request copies/representations.
Common misconceptions
Myth
The client can enforce security by hiding buttons.
Reality
UI restrictions are UX. Authorization must be enforced on the server with the authoritative state.
Myth
Server means one physical machine.
Reality
Server is a role. It may be many replicas behind a name, serverless functions, or a process on your laptop.
Myth
Peer-to-peer means no servers exist at all.
Reality
Many P2P systems still use trackers, relays, or signaling servers. Pure symmetry is rare.
Myth
If the client used HTTPS, the server application is trustworthy.
Reality
TLS secures transport. Application logic can still be wrong or malicious.
Exercises
Work these without looking up answers first. Check yourself against the intent notes.
Exercise 01
A mobile app hides the Delete button for non-admins but the API still deletes when called directly. What principle was violated?
What good looks like
Authorization must be server-side; client UI is not a security boundary.
Exercise 02
Compare hosting a game server at home versus using a cloud server in client-server terms, including NAT.
What good looks like
Home: inbound reachability blocked by NAT without forwards; cloud: public listen address, ops tradeoffs.
Exercise 03
Is a load balancer a client or a server? Argue both sides.
What good looks like
Server to end-clients; client to upstream app servers; middle role.
Sources & further reading
External references. Prefer primary documents and clear explainers.
- Peer-to-peer
medium · 2017-maps
- MDN: Client-server model (glossary-ish via web architecture reading)
high
- How the internet works
high · 2017-maps
Go deeper on your own
These picks go past the foundation in this lesson. Use them when you want a primary spec, official docs, or a longer walkthrough.
Web-focused explanation of clients initiating and servers responding. Use it to connect the pattern to HTTP apps.
- Beej's Guide to Network ProgrammingDeep dive
A well-loved free guide that builds client and server sockets from the ground up, so you can see the pattern in real code.