1.4. Client-Server Architecture

Table of Contents

Overview

Client server architecture is the basic pattern that almost every web application follows. A user’s device acts as a client, and your backend application runs as a server. They talk to each other over a network using clear rules, usually HTTP or HTTPS.

In this chapter you will see what “client” and “server” really mean, how they communicate, and how this shapes backend development. You will not learn HTTP details here, because those have their own chapters later. Here we focus on the overall structure and ideas.

What Is a Client?

A client is any program that starts a request to another program and waits for a response.

For web development, the most common client is a web browser such as Chrome, Firefox, or Safari. When you type a URL, click a link, or submit a form, the browser sends a request to a server and then shows the response.

Clients are not limited to browsers. A mobile app on a phone, a desktop application, a smart TV app, or even another backend service can be a client if it sends requests to some server.

A simple way to think about a client:

It runs on the user’s side, such as a laptop or phone.
It controls what the user sees and how the user interacts.
It does not store the main application data permanently. Instead it asks a server for data.
It can be closed at any time without breaking the server.

Imagine a weather app on your phone. The app itself is a client. It does not contain all weather data for the world. It sends a request to some weather server, waits for a response, then shows the temperature and forecast on the screen.

What Is a Server?

A server is a program that waits for incoming requests and sends back responses. It serves data or functionality to clients.

For backend development, the “server” usually means:

Your backend application code, which handles logic such as “create a new user,” “list all tasks,” or “place an order.”
A web server or application server that listens for network connections on a specific port.
Sometimes, the machine (physical or virtual) where the program runs.

A server usually:

Runs on a machine that is always connected to the network.
Listens on a fixed address and port, for example api.example.com on port 443.
Can handle many clients at the same time.
Stores and manages data, often with a database.

For example, consider a simple notes application. The server part might:

Receive a request like “create a note.”
Validate the request data.
Store the note in a database.
Send back a response that says “note created” with an ID.

The client, such as a browser or mobile app, presents a form for entering the note and shows the final result to the user. The server never shows a screen directly to the user, it only responds with data or HTML that the client then displays.

How Client and Server Communicate

The communication between client and server follows a request response pattern.

The client creates a request. For example, the browser builds an HTTP request when you open https://example.com/profile.
The request travels over the network to the server that owns that domain.
The server receives the request, processes it, and prepares a response.
The server sends the response back over the network to the client.
The client receives the response and decides what to do. A browser might render an HTML page or show an error message.

A simple text example of a full interaction:

Client: “Please send me the HTML for /home.”
Server: “Here is the HTML for the home page.”
Client: “Now please send me the CSS file /styles.css.”
Server: “Here is the CSS file.”
Client: “Now please send me the image /logo.png.”
Server: “Here is the image.”

From the user’s point of view, they only see a single page appear. But internally, it is many small request response pairs between client and server.

As a backend developer, you write the server logic that decides what to do when each request arrives.

Roles and Responsibilities in Client-Server Architecture

Client and server have different responsibilities. Understanding this separation helps you design clean backends.

On the client side, responsibilities usually include:

Showing a user interface, such as web pages or app screens.
Collecting user input, such as form data or button clicks.
Sending proper requests to the server.
Presenting the server’s responses clearly, for example by updating the page content.

On the server side, responsibilities usually include:

Defining and exposing operations that clients can use, such as “get user profile” or “update order.”
Processing incoming requests, validating them, and running business logic.
Interacting with databases and other services.
Enforcing security rules, such as authentication and authorization.
Returning clear and consistent responses.

For example, imagine a login action.

The client might:

Display a login form.
Let the user type their email and password.
When the user clicks “Login,” send these values to the server in a request.

The server might:

Receive the email and password.
Look up the user in the database.
Check if the password is correct.
If it is correct, create a session or token.
Respond with success and any needed data.
If it is not correct, respond with an error.

The client never directly checks the real password from the database. It trusts the server for authentication logic. The server never directly “shows” the login form to the user. It may send HTML or JSON, but the client controls the final display.

Request-Driven Interactions

In client server architecture, the server does not start communication with the client. Instead, the client always starts with a request.

The server waits and listens. When there is no request, it stays idle. It never randomly sends data to clients unless they have asked for it first.

You can think of it like a restaurant. The client is the customer. The server is the kitchen. The kitchen does not cook random dishes and throw them at the tables. It waits for an order. The customer orders a dish, the kitchen prepares it, then sends it back. If the customer wants more, they must place another order.

In web backends, this means:

A client must always send a new request for each new piece of information.
If the client wants to see updated data, it has to request again.
The server does not remember “who asked” unless there is some form of session or token, which you will learn about later.

Example: A Simple Task List

Consider a very basic task list application.

The client sends a request: “Give me all tasks for user 42.”
The server queries the database and replies: “Here are 5 tasks in JSON format.”
The client displays those tasks in a list on the screen.

Later, the user creates a new task.

The client sends a new request: “Create a new task named ‘Buy milk’ for user 42.”
The server adds a record to the database and replies: “Task created with ID 101.”
The client updates the screen.

These are separate requests and responses. The server does not automatically push the new list to the client. The client decides when to ask again for the full list.

Stateless vs Stateful Behavior

Client server systems can be stateless or stateful from the server’s point of view.

A stateless server treats each request independently. It does not rely on any stored memory of previous requests. Everything the server needs to know is inside the current request.

A stateful server remembers some information between requests. For example, it might remember that you logged in already. This remembered information is called state.

In web backends, HTTP is stateless by default. That means each HTTP request comes without built in memory of previous requests. To “add state,” servers use tools such as cookies or tokens, which you will study in later chapters.

For now, think of the difference like this:

Stateless: Every request includes all needed information. For example, a request to get tasks might include an authentication token, and the server uses only what is in the request and the database.
Stateful: The server may store that a particular connection or session is already authenticated and does not require a token each time.

Most modern web APIs try to keep servers as stateless as possible. This makes scaling and running many servers easier.

Important rule: Web servers should avoid storing user specific state in server memory whenever possible. Instead, state should be kept in databases, caches, or tokens that travel with each request.

One Server or Many Servers

Client server architecture can involve a single server process, or many servers working together.

At the simplest level, a personal project might have:

One client, for example your browser.
One server application that runs on your laptop on port 8000.
One database that the server talks to.

This is enough for learning and small apps.

For a real world site with many users, there might be:

Thousands or millions of clients, all around the world.
Many server instances, all running the same backend code, behind a load balancer.
One or more database servers, perhaps replicated for reliability.
Additional services, such as caching servers or message queues.

From the client’s viewpoint, it still looks like a simple client server interaction. The client sends a request to https://api.example.com and receives a response. The internal complexity is hidden behind that single entry point.

As a backend developer, you will often design your application to be ready for multiple server instances, even if you start with only one.

Example Flow: Entering a URL in a Browser

To make client server architecture concrete, let us walk through a simple example. You enter https://example.com in a browser.

Here is a high level view, without going deep into networking details.

The browser acts as a client and needs to know which server to talk to.
It uses DNS to find the IP address for example.com. That part belongs to later chapters.
Once it has the IP address, the browser opens a network connection to the correct server machine.
The browser sends an HTTP request to that server. The request is something like “GET /.”
The server application receives the request. Its router decides which piece of code should handle the path /.
The code runs. It may query a database, read templates, and build HTML.
The server sends an HTTP response back to the browser with status and body.
The browser receives the response and renders the HTML so the user sees a webpage.

Notice the roles.

The client started everything by sending a request.
The server only responded, it did not open the connection on its own.
The client controlled what to display in the end.

You will learn the detailed step by step version of “What happens when you enter a URL” later. For now, recognize that this whole process is just one specific example of client server architecture.

Client-Server and Backend Development

As a backend developer, you focus on the server side of this architecture.

Your main tasks are:

Defining what operations clients can request, such as “get all products” or “create an order.”
Designing how requests and responses look, for example which URLs and which data formats.
Implementing server logic that processes requests safely and efficiently.
Interacting with databases and other services behind the server.
Ensuring the server behaves correctly when many clients connect at the same time.

You will usually not write the entire client side yourself, although for learning you might create simple HTML pages or test clients. In many teams, frontend developers or mobile developers build the client parts that talk to your backend.

You need to think about:

What can a client do with my server?
What data does the server need from the client?
What will the server send back?
How can I make it easy and safe for many different clients to use this server?

Client server architecture is the foundation of all these decisions. Every REST API, every web page, every mobile app backend is built on this basic pattern.

Summary

Client server architecture describes a simple but powerful idea. A client sends requests, a server waits for them and sends back responses. The client manages the user interface, the server manages business logic and data. HTTP based web applications are just one example of this general pattern.

Understanding this separation of roles will help you make sense of everything else in backend development, from routing and APIs to databases and authentication.