Client-Server Architecture
Client-server architecture is the foundational network model underlying most web and mobile systems: clients (browsers, mobile apps, other services) initiate requests, and servers listen for those requests, process them, and return responses, typically over a network using a defined protocol such as HTTP. The model centralizes shared logic, data, and business rules on the server side, letting many heterogeneous clients (a web app, an iOS app, a third-party integration) reuse the same backend capabilities without duplicating logic, while clients remain responsible for presentation and local interaction. This separation of concerns is what makes independent evolution of client and server possible — a mobile app can be updated without redeploying the backend, and the backend can be scaled or rearchitected without every client needing to change.
Cricket analogy: A cricket board's central scoring office processes ball-by-ball data and business rules once, letting the TV broadcast graphics, the stadium jumbotron, and a fan's mobile app all display the same official numbers without each reinventing the scoring logic.
Thin vs Thick Clients
The distribution of responsibility between client and server varies along a spectrum. A thin client pushes almost all logic and state to the server, with the client mainly rendering server-provided HTML or data (classic server-rendered web apps); a thick client (a modern single-page app or native mobile app) handles significant logic, state management, and even offline caching locally, communicating with the server primarily through an API. Thick clients reduce server load and improve perceived responsiveness (fewer round trips for UI updates) but increase client-side complexity and can create version-skew problems when many client versions are in the wild talking to an evolving server API.
Cricket analogy: A stadium's old paper scoreboard operator (a thin client) just displays whatever the central scoring office radios over; a modern broadcast graphics team's tablet (a thick client) calculates its own projected required run rate locally and only pulls raw ball data from the server.
Scaling the Server Side
Because clients are typically numerous and servers are comparatively few, the server side is where system design effort concentrates: a single server handling all client requests becomes a bottleneck and single point of failure as client count grows, which motivates load balancing across a fleet of stateless servers, horizontal scaling, and the layered architectures (load balancer, application tier, cache, database) covered elsewhere in this course. The client-server model itself doesn't mandate any particular scaling strategy — it simply establishes the request/response contract that everything else is built on top of.
Cricket analogy: With millions of fans hitting one central scoring server during a World Cup final, that single server becomes the bottleneck; the broadcaster instead fronts it with a load balancer distributing requests across many identical scoring-relay servers.
Client (browser/app) Server
|--- HTTP GET /api/users/42 ------->|
| | (process request,
| | query database)
|<---- 200 OK { user data JSON } ---|
Multiple heterogeneous clients, one shared backend:
[Web App] \
[iOS App] >---> [API Server(s)] ---> [Database]
[Android] /REST APIs are the most common realization of client-server architecture on the modern web: they formalize the request/response contract using HTTP verbs (GET, POST, PUT, DELETE) and status codes, letting any client capable of making HTTP requests interoperate with a server regardless of the client's implementation language or platform.
A subtle mistake is conflating 'client-server' with 'client-server means one big server.' In practice, the 'server' side of the architecture is usually itself a distributed system — a fleet of stateless application servers behind a load balancer, backed by databases and caches — the client-server model describes the relationship at the network-protocol level, not the internal implementation of either side.
- Client-server architecture separates request-initiating clients from response-providing servers, centralizing shared logic and data on the server.
- This separation allows clients and servers to evolve independently as long as the API contract between them is preserved.
- Thin clients push most logic to the server; thick clients handle significant logic and state locally, trading server load for client complexity.
- The server side is usually where scaling effort concentrates, since it serves many clients simultaneously.
- REST over HTTP is the most common concrete implementation of the client-server model on the web.
- 'Server' in client-server architecture often refers to a distributed fleet, not a single physical or logical machine.
Practice what you learned
1. What is the core relationship defined by client-server architecture?
2. What is the main difference between a thin client and a thick client?
3. Why does system design effort typically concentrate on the server side rather than the client side?
4. What is a common misconception about the term 'server' in client-server architecture?
5. What benefit does the client-server separation of concerns provide?
Was this page helpful?
You May Also Like
What Is System Design?
An introduction to the discipline of designing large-scale software systems, covering what system design means, why it matters, and how it differs from low-level coding.
Stateless vs Stateful Services
Explains the distinction between services that retain per-client state locally versus those that don't, and why statelessness is central to scalable system design.
Load Balancing Algorithms
Surveys the algorithms load balancers use to distribute traffic across backend servers, from simple round robin to adaptive least-connections and consistent hashing.
REST vs gRPC vs GraphQL
A comparison of three dominant API communication styles — resource-oriented REST, high-performance binary gRPC, and flexible query-driven GraphQL — and when to choose each.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 40 topics
Software EngineeringGit & Version Control Study Notes
Bash · 40 topics