Client-Server Model
How clients and servers communicate over a network to power most applications
Overview
The client-server model splits an application into a client that requests resources and a server that provides them. This separation lets many clients share centralized data and logic while the server controls access and consistency. Almost every web and mobile app follows this pattern.
Syntax / Usage
A client (browser, mobile app, or another service) opens a connection to a server, sends a request, and waits for a response. Communication usually happens over HTTP, often secured with TLS (HTTPS).
Client Server
| GET /users/42 ------------> |
| | look up user 42
| <----- 200 OK + JSON ------- |
The client is typically stateless about server internals, and the server is often designed to be stateless too, storing session data in a database or cache so any server instance can handle any request.
Examples
A weather app on your phone is the client; it sends an HTTP request to a weather API server, which returns JSON that the app renders. The phone holds no weather data permanently.
A multiplayer game may use a persistent connection (WebSocket) so the server can push updates to clients in real time, instead of clients repeatedly polling.
Common Mistakes
- Storing session state on one specific server, breaking things when requests hit another
- Trusting the client for validation or security-critical logic
- Ignoring network failures and timeouts between client and server
- Sending too much data per request instead of paginating
- Confusing the physical machine with the logical role (one machine can be both)
See Also
system-design-fundamentals system-design-apis system-design-load-balancing