Multi-Tier Architecture

A software application generally has the following layers (also referred to as tiers):

• The User Interface (UI)
  This is the tier that interacts with the user, accepting inputs and displaying outputs. There can be a lot of logic built into this tier to provide a good user experience, including validation of inputs and formatting of output.

• Processing
  This is the tier that has most of the application logic. It receives inputs from the UI tier and also sends back output to the UI tier. If any data needs to be stored it passes that data to the Database tier.

• Database
  This is is the layer that stores application data for the long term. The processing tier writes and reads data as required from the database tier.

Client-Server Architecture

As mentioned above, an application has three functional tiers, while a client-server architecture has only two tiers. This implies that one of these tiers must do the job of two.

A client-server architecture distributes application tasks between clients and servers. Clients generally initiate some action while servers wait for a request from the client and then execute the requested task. Often clients and servers run on different computers and communicate over a network, but both may reside on the same computer.

One example of a client-server architecture is an email application. You need to install an email client on your computer (could even be your web browser) and set up a connection to an email server that is either managed by the organization you work for or a public email service provider (such as Gmail).

When you want to send an email to someone, you type it out in your client application. At this point, the server is doing nothing, awaiting some instruction from the client. When you are done typing your email, you enter the recipient email address and click on the 'Send' button. The client now sends a request to the server to send the email content to the recipient. When it receives the request, the server gets busy. It determines if the recipient's address is valid, and if valid, it sends the email content to the recipient.

Since the recipient is also using an email client connected to an email server, the sender's server sends the message to the recipient's server. The message sits there until the recipient runs the email client and asks the server if it has any messages. At that point, the recipient's email server delivers the email content to the recipient's client. The same flow takes place in the reverse direction when the recipient replies to the sender's email.

But the client-server paradigm goes a little beyond just the two-tier concept. When you design more complex architectures with multiple tiers, any program in a tier that makes a request to a program in another tier can be considered to be acting in a client-server relationship. So while the web browser may always act as a client to the web server, when the webserver requests data from the database server, it becomes a client.

Separation of Duties

Application architecture tiers are guidelines, not rules. While generally the UI and database tiers cannot be replaced, it is possible to build all of the processing logic in the UI or the database. This would lead to a 2-tier architecture, with just the UI and the database.

As applications become more complex, the separation of duties principle becomes a strong guideline. A well-architected application would ensure that each tier did only what it should do and can do best and do nothing that the other tiers should do. For example, the UI layer should only have the instructions to receive and validate input and pass it on to the processing tier. It should not have any processing logic. Similarly, the database tier should only store data received from the processing tier and make it accessible to the processing tier as required. Further, at no time should a tier connect across another tier. For example, the UI tier should never connect directly to the database tier.

Today, the application complexity has reached a level where more than three tiers are required, and this is referred to as an N-tier architecture, where N can be any number.

See the illustration below for an n-tier architecture, for a traditional web/mobile app and for an IoT solution with sensors as the client sending data.