New version!

A new version of this website is available at architectural-patterns.net.

Client-Server / N-Tier Systems

N-Tier architectures are hot. Well, maybe not as hot as a few years ago, but still it is very important you know about them. All web applications are N-Tier architectures. You have an application server, a large number of clients, and a database. An N-Tier architecture is really a Client-Server architecture combined with the Layered architecture. The reason why I combine Client-Server and N-Tier here is because they are very much related.

A Tier is a just a Layer, yet Tiers are commonly physically removed from each other. The meaning of a tier is:

One of a series of rows placed one above another: a stadium with four tiers of seats.

A Client-Server system is one in which the server performs some kind of service that is used by many clients. The clients take the lead in the communication. The basic Client-Server architecture has 2 tiers (Client and Server). I will basically explain the 3-tier architecture here, which is an extension to the 2-tier architecture.

The first, or presentation tier, a.k.a. the client or front-end, deals with the interaction with the user. Usually, there can be any number of clients which can all access the server at the same time. Currently the clients are mostly thin clients, which means they do not contain a lot of application code (in contrast to fat clients). Clients process user input, send requests to the server, and show the results of these requests to the user. A common client is made up of a number of dynamic HTML pages that one can access with a web browser.

The second, or application tier, a.k.a. the server, or the back-end, or middleware, processes the requests of all clients. It is the actual web application that performs all functionality specific to the web application. However, it does not store the persistent data itself. Whenever it needs data of any importance, it contacts the database server.

The third, or database tier contains the database management system that manages all persistent data.

It is clear that there are multiple clients. That's what client-server computing is all about. However, in the second and third tier there can also be multiple instances of the same application. If this is the case, it is because of scalability, load-balancing and redundancy. Which means the system is important, so let's add extra equipment that does the same thing. This makes the server a very powerful system, but also introduces synchronisation problems.

Examples

  • Web-applications. Where the first tier is the application-tier, the second tier is the application tier and the third tier is the database tier.

Where does it come from?

At the advance of multitasking operating systems in the nineteen-sixties, it became possible to access a single computer (the server) from different terminals (clients). The distance between the clients and the server became bigger and the number of clients increased. At the time the application and database tiers were still integrated. It is called client-server computing.

With the booming of the Internet and e-commerce in the nineteen-nineties, the architecture became important, and much time and money was invested in it. As other good architectures have shown, it is a good idea to separate the application code from the data. This principle was applied to the client-server architecture. Companies created application servers to ease the creation of web applications.

An N-tier architecture (with N more than 3) is really 3 tier architectures in which the middle tier is split up into new tiers. The application tier is broken down into separate parts. What these parts are differs from system to system. The following picture shows it:

When should you use it?

You don't usually need to build your own application and database server. Most application developers either build the application specific front-end code, or the application specific back-end code. This code is then embedded in an existing application server and uses an existing database management server.

How does it work?

The architecture is so generic it is hard to say anything concrete about it. Communication between the different tiers often takes place via a network. Communication within a tier also is done over a (local) network. Clients don't communicate directly to each other. Clients communicate to the application server directly or to a broker that balances requests between separate server machines. The database layer usually contains only one database.

Links