software engineering – What is the difference between client-server and three-tiers?


In the Software Design ( SWEBOK ) chapter, when talking about architectural styles, client-server and three-tiers are mentioned:

Various authors have identified a number of major architectural styles : distributed systems (for example, client-server, three-tiers ) […]

I don't quite understand the difference between these architectural styles. Also, it looks like these styles are outside the scope of software design .



The client-server is a two-tier model where you usually have a software component that interacts with the user or operates something on the more visible front of a system, while the server is responsible for doing more specific work in another physically separate part. .

An easy example is what we find on the web where you have the browser acting as a client and the HTTP server obviously acting as a server, so one of them starts the whole action requesting something to the server that knows what to do with that request and delivers the result to the client operates as it sees fit, in which case it renders an HTML page and the like.

Another example that is often cited and that is still client-server, but the way they use it is a little wrong is the desktop application that accesses another service which is a database, so the first is the client and the DB would be the server. I think this is an error because the database is not part of your architecture so you even have a client and a server, but your system cannot be classified like that, the solution as a whole is even a client-server .

It is common for each of these two parts to be on separate machines on the same network or on another, but nothing prevents them from being on the same, there are several cases like this, but it is just not usually so visible. In a way, all consumption of operating system services is like this always has its application as a client and the operating system is the server. It is important to note this because the invisibility of the hardware gives the impression of being one and the same, but the fact that the software is separate indicates that there is a service being consumed by a client.

It is less common for people to see this (which is not to say that it is unusual to exist) but there are different client-server architectures, for example a windowing system where what you see is the client but more internal processing is done by another one quite isolated component that is the server, this is interesting because it gives the advantages mentioned below, the X-Window is an example.

This type of architecture can provide more security, scalability, flexibility (can exchange components, access remotely, interoperability), and in some cases more performance (despite a certain overhead that this generates), in addition to simplifying the operation, at least in a certain point of view. In the context of the question the distribution becomes simple as there is a clear separation of each part.

The fundamental point is that it has a requester and a deliverer of results.

3 layers

When you add a component in the middle to intermediate the process, usually called middleware, you have a 3 layer architecture. This middleware can delegate certain tasks to another layer, coordinating that work. In general, the complexity increases and the gain is not always obvious, so it is less common to find this type of architecture. Nowadays, either the client-server is pure or it is opted for something more decentralized, accessing what would be a third layer directly by the client, distributing the work even more.

Some people consider that if you have a client, an application server and a database you have 3 tiers, again I think it's a mistake, but informally it might be acceptable. So some people consider that a typical web system is like that since it has the browser , the HTTP server and the database. At least it's a simple way to understand.


These architectures should not be used to organize development.

Just be careful with 3 tiers and 3 layers , which we usually translate both to 3 tiers.

The first is an architectural pattern of the software components where 3 separate deploys are made and therefore it is comparable with the client-server and can be distributed, within the context of the question.

The second is a code organization pattern, it's something more internal and doesn't need to generate different software components. It is common to have the 3 only on the server, or just on the client or even just on the middleware (less common because this tends to be a "traffic guard" of the solution, so it is not a distribution pattern that is mentioned in SWEBOK ( its context makes the separation clearer.) It is not common to talk about 3 tiers, so if you search you will find more about 3 layers .

MVC is a known 3-layer form in this regard. This is a case for organizing development.

Excerpts from SWEBOK that give more context:

A distributed system is a collection of physically separate, possibly heterogeneous computer systems that are networked to provide the users with access to the various resources that the system maintains. Construction of distributed software is distinguished from traditional software construction by issues such as parallelism, communication, and fault tolerance. Distributed programming typically falls into one of several basic architectural categories: client-server, 3-tier architecture, n-tier architecture, distributed objects, loose coupling, or tight coupling algorithm selection—influences an execution speed and size.

If the excerpt were copied completely in the question, maybe it would give more context that they are items of physical separation since 3 examples are more disambiguous:

Distributed systems (for example, client-server, three-tiers, broker)

For context, the broker is a form of middleware used in SOA (Service-oriented Architecture), something that has been supplanted by microservices (for me both are wrong in almost every scenario)


Middleware is a broad classification for software that provides services above the operating system layer yet below the application program layer. Middleware can provide runtime containers for software components to provide message passing, persistence, and a transparent location across a network. Middleware can be viewed as a connector between the components that use the middleware. Modern message-oriented middle-ware usually provides an Enterprise Service Bus (ESB), which supports service-oriented interaction and communication between multiple software applications.

Source .

Scroll to Top