Client-Server Model

A system architecture where one program (the client) asks for something and another program (the server) processes the request and sends back a response.

What is the client-server model?

Every time you open a web browser and visit a page, two computers are having a conversation. Your computer (running the browser) is the client — it asks questions. A remote computer somewhere on the internet is the server — it answers them.

The client sends a request: “Give me the homepage.” The server receives that request, figures out what to send back, and returns a response: the HTML, CSS, and JavaScript that make up the page. This back-and-forth is called the request-response cycle, and it is the foundation of how the web works.

The two sides never switch roles. The client always initiates. The server always waits, listens, and responds. This clear division of responsibility is what makes the model so reliable — each side has a well-defined job.

In plain terms

The client-server model is like a post office. You (the client) write a letter with a specific question and address it to a recipient (the server). The post office delivers it. The recipient reads your letter, prepares an answer, and sends a reply back through the same postal system. You never visit the recipient’s house directly — you always go through the postal system.

At a glance

How a request-response cycle works (click to expand)
sequenceDiagram
    participant B as Browser (Client)
    participant S as Server
    participant D as Database

    B->>S: HTTP Request ("GET /products")
    S->>D: Query for data
    D-->>S: Return results
    S-->>B: HTTP Response (HTML + CSS + JS)
    Note over B: Renders the page
Key: The browser sends a request using HTTP. The server may query a database, then assembles and returns a response. The browser renders the result into what the user sees.

How does the client-server model work?

Every interaction follows the same pattern. Understanding the four pieces below gives you the full picture.

1. The client

The client is the program that starts the conversation. In web development, this is usually a web browser — Chrome, Firefox, Safari. But clients can also be mobile apps, desktop applications, command-line tools, or even other servers.

The client’s responsibilities:

Send requests to the server
Receive and display responses (render HTML, show images, play video)
Handle user interaction (clicks, form input, scrolling)

The client never accesses data storage directly. It only sees what the server chooses to send back.

Think of it like...

A customer at a service counter. You can ask questions and receive answers, but you cannot walk behind the counter and access the filing cabinets yourself.

Concept to explore

See frontend for a deeper look at what the client side involves in web development.

2. The server

The server is a program running on a remote computer that listens for requests and processes them. “Server” can mean the physical machine or the software running on it — in practice, it usually refers to the software.

The server’s responsibilities:

Listen for incoming requests on a specific port (usually port 80 for HTTP, 443 for HTTPS)
Process the request (run code, query a database, apply business logic)
Return a response with a status code and data

A single server can handle requests from thousands of clients simultaneously.

Think of it like...

A librarian at a reference desk. They wait for questions, look up answers using resources the visitor cannot access directly, and hand back the results.

Concept to explore

See backend for what happens on the server side of a web application.

3. The request

The client sends a structured message called an HTTP request. Every request includes:

Part	What it does	Example
Method	What action to perform	`GET`, `POST`, `PUT`, `DELETE`
URL	Where to send it	`https://example.com/products`
Headers	Metadata about the request	`Accept: text/html`
Body	Data being sent (optional)	`{ "name": "New item" }`

A request in plain English (click to expand)
“GET me the page at /products, and send it as HTML.”

Translated:
GET /products HTTP/1.1
Host: example.com
Accept: text/html

4. The response

The server sends back an HTTP response containing:

Part	What it does	Example
Status code	Did it work?	`200` (yes), `404` (not found)
Headers	Metadata about the response	`Content-Type: text/html`
Body	The actual content	HTML, JSON, an image, etc.

Common status codes:

Code	Meaning
`200 OK`	Success — here is your data
`301 Moved`	The resource has a new address
`404 Not Found`	That resource does not exist
`500 Server Error`	Something broke on the server

Concept to explore

See http-protocol for the full rules governing how requests and responses are formatted.

Key properties

Three properties define this model:

Stateless by default. Each request is independent. The server does not remember the previous request unless you build mechanisms for it (cookies, sessions, tokens). Every request must carry all the information the server needs.

Client-initiated. The server never spontaneously contacts the client. It only responds when asked. (Technologies like WebSockets add exceptions to this rule, but the default model is always client-first.)

Location-independent. The client and server can be on the same machine, in the same building, or on different continents. The protocol works the same way regardless of physical distance.

Why do we use the client-server model?

Key reasons

1. Separation of concerns. The client handles what the user sees; the server handles data and logic. Each side can be built, updated, and scaled independently without breaking the other.

2. Centralised data. All clients connect to the same server, so everyone sees the same data. Updates happen in one place, and every client gets the latest version on the next request.

3. Security. Sensitive data and business logic live on the server, behind a controlled interface. Clients never have direct access to the database or internal systems.

4. Scalability. You can add more servers to handle more clients without changing the client software at all. The model naturally supports growth.

When do we use the client-server model?

When building any web application — every website uses this model
When multiple users need to share the same data (a product catalogue, a social feed, a knowledge base)
When you need controlled access to data (authentication, authorisation, rate limiting)
When the processing is too heavy for the client device (database queries, machine learning, file processing)
When building APIs that serve data to multiple types of clients (web, mobile, third-party tools)

Rule of thumb

If your application needs to store data that outlives a single user session, or if multiple users need access to the same data, you are building a client-server system.

How can I think about the client-server model?

The restaurant

A restaurant is a client-server system.

You (the diner) are the client — you place orders

The kitchen is the server — it processes orders and produces results

The menu is the API — it defines what you can order and in what format

The waiter carries messages back and forth — that is the HTTP protocol

The pantry is the database — where ingredients are stored

You never enter the kitchen. The kitchen never comes to your table uninvited. Each side has a clear role.

The bank teller

A bank is a client-server system.

You are the client — you walk up and make a request (“I’d like to withdraw CHF 200”)

The teller is the server — they verify your identity, check your balance, and process the transaction

The vault is the database — where the actual money lives

You never access the vault directly. The teller enforces rules (you cannot withdraw more than your balance). If the system is down, the teller tells you to come back later (a 503 response).

Concepts to explore next

Concept	What it covers	Status
frontend	The client side — what runs in the browser	complete
backend	The server side — logic, data, security	complete
apis	The contract between client and server	complete
databases	Where the server stores persistent data	complete
http-protocol	The rules for formatting requests and responses	stub
dns	How domain names get translated to server addresses	stub
tcp-ip	The lower-level transport that carries HTTP	stub
websockets	Real-time two-way communication (the exception to client-initiated)	stub

Some of these cards don't exist yet

They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.

Check your understanding

Test yourself (click to expand)

Explain the client-server model to someone who has never built software. Use the restaurant or bank teller analogy.

Name the four parts of a request-response cycle and describe what each one contains.

Distinguish between the responsibilities of the client and the responsibilities of the server. Why can the client not access the database directly?

Interpret this scenario: you type a URL into your browser and see a “404 Not Found” page. What happened in the request-response cycle?

Connect this concept to separation-of-concerns: how does the client-server model enforce separation between presentation and logic?

Where this concept fits

Position in the knowledge graph
graph TD
    SA[Software Architecture] --> CSM[Client-Server Model]
    CSM --> FE[Frontend]
    CSM --> BE[Backend]
    CSM --> API[APIs]
    CSM --> DB[Databases]
    SA --> SOC[Separation of Concerns]
    style CSM fill:#4a9ede,color:#fff
Related concepts:

http-protocol — the language clients and servers use to communicate; defines the format of every request and response

separation-of-concerns — the design principle that the client-server model puts into practice

Yiuno

Explorer

Client-Server Model

Client-Server Model

What is the client-server model?

At a glance

How does the client-server model work?

1. The client

2. The server

3. The request

4. The response

Key properties

Why do we use the client-server model?

When do we use the client-server model?

How can I think about the client-server model?

Concepts to explore next

Check your understanding

Where this concept fits

Further reading

Graph View

Table of Contents

Backlinks