Skip to main content

Client-Server Architecture

Client-server is the default architectural shape this entire course has assumed without saying so: a client initiates a request, a server holds resources and processing power the client doesn't, and responds. Every HTTP request, every API call, every database query is an instance of this same asymmetric relationship — one side asks, the other side is authoritative and answers. It's worth pausing on it explicitly as an architectural choice, because Peer-to-Peer Architecture exists specifically as its counterpoint.

The asymmetry is the whole design​

A client is typically lightweight and doesn't need to be reachable by anyone else — a browser tab, a mobile app, another service making an outbound call. A server is the opposite: centrally reachable, holding the actual data or computation, built to handle many clients concurrently. This asymmetry is what makes almost every earlier lesson in this course possible in the first place: a Load Balancer can spread client requests across many interchangeable server replicas precisely because clients don't know or care which specific server instance answers, and a server can be scaled, replicated, or replaced without any client noticing, as long as the same contract holds.

System Design Lab

What centralization buys — and what it costs​

Centralizing authority in the server is what makes a system's data easy to reason about: there's one place ACID Transactions are enforced, one place access control is checked, one place to look for the current, correct state of anything. That same centralization is also exactly what makes the server a Single Point of Failure unless it's deliberately made redundant — a client-server system's entire reliability story rests on how well the server side handles Scalability, Availability, and Failover, because the client side, by design, isn't built to pick up that slack.

Every pattern in this course lives on one side or the other​

It's worth noticing, now that most of this course has been covered, that nearly every pattern discussed so far is really about scaling or protecting the server side of this relationship — Database Sharding, Caching, Circuit Breakers, Service Discovery — because the client-server model concentrates almost all of a system's hard problems on the server. A Microservices Architecture doesn't abandon client-server at all; it just turns "the server" into many smaller servers, each client-server pair in its own right, calling each other.

When the model itself doesn't fit​

Client-server assumes a natural asymmetry — someone has the authoritative data, someone else wants it. Some problems don't have that shape at all: sharing files directly between equally-capable machines with no natural single authority, for instance, is exactly the case Peer-to-Peer Architecture is built for instead, where every participant can act as both a client and a server to its peers.

Why this matters in an interview​

Client-server is such a strong default that it rarely needs to be named explicitly — but recognizing when a design doesn't fit it is a genuinely useful signal. If a system has no natural central authority, needs to keep working with no server reachable at all, or is explicitly trying to avoid a company running (and being a target for) central infrastructure, that's the moment to name peer-to-peer as the deliberate alternative, rather than defaulting to client-server out of habit.

Client-server vs. peer-to-peer: pros and cons​

Client-server

  • One authoritative place for data and access control, easy to reason about
  • Centralized infrastructure can be scaled, monitored, and secured as one thing
  • The vast majority of tooling, frameworks, and operational knowledge assumes this model

Peer-to-peer

  • No natural central authority, so consistency and access control are harder to enforce
  • Requires solving discovery and coordination without a central server to rely on
  • Debugging and monitoring a system with no single authoritative vantage point is harder

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.