The client–server model and multi-tier systems

Objectives

By the end of the lesson, you can explain the roles of the client and the server, describe the request–response model, and justify why larger web systems are split into layers.

Why do we need this model?

When a student clicks the "Enrol in course" button, they see a single action. For the system it is a series of questions: who started it, are they authorized, is there still room, are the prerequisites met, and how do we record the result permanently? The roles and layers answer the question of which part is responsible for what, so that the checks happen not in the browser but in a trustworthy place.

Client and server

A client is a program or device that requests a service. On the web this is typically the browser. A server is a system that receives the request, processes it, and sends a response. The roles always refer to one specific communication: the same machine can be a client at one time and a server at another.

When the browser requests a course page, it is a client. The Kurzuspont server responds. If the Kurzuspont application calls the API of an email service meanwhile, in that connection the application is the client and the email service is the server.

Request and response

The basic communication pattern of the web is the request–response model. The client initiates, the server responds. The server does not speak to the client on its own; if that is needed anyway, there are separate solutions (chapter 5).

1. The user opens an address.
2. The browser sends a request to the server.
3. The server may check authorization, fetch data, or perform an operation.
4. The server sends a response, which contains whether it succeeded, and the data.
5. The browser interprets and displays the response.

A request does not always ask for a whole web page: it can also be an image, data, a search result, a login, or a file upload.

sequenceDiagram
    actor F as User
    participant K as Browser (client)
    participant S as Web service (server)
    F->>K: Start an action
    K->>S: Request
    S-->>K: Response or error signal
    K-->>F: Display the result

Why do we split the system into layers?

In a small system all tasks fit in a single application. As the system grows, it is worth separating the different responsibilities so that one change does not shake the whole thing. The classic three-tier model:

Tier	Main task	Example in Kurzuspont
Presentation tier	Contact with the user, display	Browser interface, forms, tables
Application (business) tier	Rules, processes, permissions	Checking the conditions of enrolment
Data tier	Storing and querying data	Students, courses, enrolments

Advantage: for example, replacing the database ideally does not require redesigning the interface. Disadvantage: there are more parts to coordinate.

flowchart LR
    P[Presentation tier: interface] --> A[Application tier: rules]
    A --> D[Data tier: storage]

Logical and physical separation

Solution	Advantage	Limitation
One application, one machine	Simple development and operation	Limited scalability, one fault affects several functions
Logically layered system	Clear responsibilities	Requires design discipline
Physically separated tiers	Better scalability and protection	More complex communication and operation

The goal is not always the largest number of tiers: a good architecture fits the real needs.

Worked example: enrolling in a course in Kurzuspont

1. The browser sends the student's request to the server: "enrol me in this course".
2. The application tier checks whether the student is logged in, has met the prerequisites, and whether there is a free place.
3. The data tier records the enrolment.
4. The application tier prepares the result.
5. The browser displays the success or the justified refusal.

The browser does not "rewrite the database" directly. If it did, anyone who modified the browser could bypass the rules. The check therefore happens on the server, in a trusted environment; chapter 8 will elaborate this thought (the client is not trustworthy).

Common misconceptions

Statement	Clarification
"The client is always a user's computer."	The client can also be another server-side application.
"The server is a single machine."	The server is a role, which several machines or services can fill.
"The three tiers must run on three machines."	The tiers are primarily logical areas of responsibility.
"The browser connects directly to the database."	Usually the application tier mediates and enforces the rules.

In brief

• The client requests, the server responds; the roles can change from one communication to another.
• The basic pattern of the web is request–response.
• Layering separates areas of responsibility; it can be logical and physical too.
• The rules must be enforced on the server, because the client is not trustworthy.

Review questions

1. When can the same program be a client and a server at the same time?
2. What is the task of each of the three tiers?
3. Why is it not enough to check the conditions of enrolment in the browser?
4. What does it mean that the logical separation of the tiers is not the same as the physical separation?

Learning resources

• How the web works (MDN) — the concepts of client and server.
• HTTP Semantics, RFC 9110 — the official description of the request–response model; advanced reading.