The client-server model is a classic architecture of distributed systems. It is based on dividing responsibilities between a client (who requests services) and a server (who responds to those requests). This pattern is present in almost all the modern web and in multiple types of applications.
# History and Evolution
In the 60s and 70s, mainframes dominated: central computers with dumb terminals. As PCs emerged, it became viable to divide processing: clients could interact with centralized servers. With the arrival of the Internet, this model exploded in popularity and became the basis of web architecture.
# General Operation
-
The client initiates a request over a network.
-
The server receives it, processes it, and responds.
-
Everything happens under protocols like HTTP, TCP/IP, etc.
# Everyday Analogy
Imagine a restaurant. You (client) order a dish. The waiter (server) takes the order, takes it to the kitchen, and then returns with the dish. The client never gets involved with how the food is cooked; they only make requests and receive responses.
# Advantages
-
verified
Simplicity
Easy to understand and implement.
-
verified
Separation of Concerns
Allows separating interface (client) and business logic (server).
-
verified
Horizontal Scalability
Allows multiple clients for the same server.
# Disadvantages
-
warning
Coupling
High coupling with the server.
-
warning
Single Point of Failure
If the server goes down, everything is lost.
-
warning
Latency
Latency and performance problems with many clients.
# Technical Example (Node.js)
Server with Express
const express = require('express');
const app = express();
app.get('/api/time', (req, res) => {
res.send(new Date().toLocaleTimeString());
});
app.listen(3000, () => console.log('Server listening on port 3000'));
Client (HTML + JS)
<button onclick="requestTime()">What time is it?</button>
<script>
function requestTime() {
fetch('http://localhost:3000/api/time')
.then(response => response.text())
.then(alert);
}
</script>
# Conclusion
The client-server model has not disappeared: it remains alive within many other modern architectures like REST, GraphQL, microservices, and serverless. Learning this model is essential to understand how information flows between layers of an application, how to design APIs, and how to build robust systems.