Client vs Server
In networking, a client is a device or program that requests information or a service, and a server is a device or program that provides that information or service in response.
When your browser loads a website, your browser is the client making the request, and the web server is the machine sending back the page. This client-server relationship is the foundation of how the internet and most business systems work.
Client vs Server, explained at three levels
At home
A client is the device or app that asks for something — when you open your browser and go to a website, your browser is the client. The server is the computer on the other end that receives your request and sends back the website. Every time you use the internet, your device acts as a client communicating with various servers — one for email, one for social media, one for streaming, and so on.
At work
In business, most applications follow the client-server model: employees use client software (a browser, a desktop application, or a mobile app) to interact with data and services hosted on servers. Understanding this distinction helps non-technical stakeholders appreciate why both ends matter — a perfectly functioning server is useless if the client software is outdated, and the best client experience depends on a responsive, reliable server behind it.
At home
Clients can be 'thin' (doing minimal processing, relying on the server for most logic — like a web browser) or 'thick' (running significant application logic locally — like a desktop application that syncs with a server). The client initiates communication by sending a request; the server listens for requests, processes them, and returns a response. APIs (Application Programming Interfaces) define the contract between clients and servers — what requests are valid, what data format to use, and what responses to expect.
At work
The client-server model has implications for architecture decisions across security, scalability, and deployment. Server-side processing centralises logic and data, simplifying security and consistency. Client-side processing (as in modern Single Page Applications) offloads work from the server and improves perceived responsiveness but distributes logic across potentially uncontrolled environments. In enterprise environments, managing client software versions (browsers, desktop agents, mobile apps) is a significant operational consideration that affects compatibility and security posture.
At home
Modern architectures often blur the traditional client-server boundary. Peer-to-peer (P2P) systems allow devices to act as both client and server simultaneously. Edge computing moves server-like processing closer to the client. Service meshes in microservice architectures create chains where a server receiving a client request itself becomes a client to downstream services. WebSockets and server-sent events (SSE) enable the server to push data to the client without a request, reversing the traditional interaction pattern for real-time applications.
At work
At enterprise scale, client management involves MDM (Mobile Device Management) and UEM (Unified Endpoint Management) platforms that enforce configuration, security policies, and software versions across thousands of client devices. On the server side, service-oriented and microservice architectures decompose monolithic servers into many smaller services, each acting as both a server to its consumers and a client to its dependencies. Distributed tracing across this chain of client-server interactions is essential for diagnosing latency, errors, and cascading failures in complex systems.
Real-world examples
At home
When Ravi opens a music streaming app on his phone and presses play on a song, his phone (the client) sends a request to the streaming service's server. The server finds the song file and streams it back to Ravi's phone. His phone handles the playback; the server handles finding and delivering the music.
At work
When Laura opens the CRM system at work, her browser (the client) connects to the CRM server hosted in the cloud. The server authenticates Laura's login, retrieves her dashboard data from the database, and sends it to her browser for display. Every action Laura takes — searching contacts, updating a deal, generating a report — is a client request that the server processes and responds to.
How it compares
| Aspect | Client | Server |
|---|---|---|
| Role | Requests services and data | Provides services and data in response |
| Examples | Web browser, mobile app, desktop application | Web server, database server, email server |
| Who initiates | The client sends the first request | The server waits for requests and responds |
| Location | On the user's device (laptop, phone, tablet) | In a data centre, server room, or cloud platform |
| Quantity | Many clients connect to one server simultaneously | One server (or cluster) serves many clients at once |
| User interaction | Provides the interface the user sees and interacts with | Operates behind the scenes with no direct user interface |
The client requests; the server responds. This simple relationship underpins virtually all networked computing, from web browsing to enterprise applications. Understanding which side does what helps clarify architecture, troubleshooting, and system design conversations.
For analysts
When documenting system architecture, clearly identify what runs on the client side and what runs on the server side. This distinction affects user experience, security, offline capability, deployment strategy, and testing scope. If the business requirement says 'the system must work offline,' that implies significant client-side logic and storage — a very different architecture from a system that requires constant server connectivity.
History & origin
The client-server model was formalised in the 1980s as networked computing replaced standalone mainframe terminals. It provided a clearer division of responsibilities: servers centralised data and processing, while clients handled user interaction. This model has evolved — from thick clients that ran significant local software, to thin clients that relied on the server for everything, to today's web and mobile applications where the balance shifts depending on the architecture.