What is 3 Tier Architecture and Why Do You Need It?

Three-tier or multi-tier architecture is often used when describing how clients connect to database servers. But what does it all mean?

Let me try to explain this in non-technical terms (or as close to it I can get).

 

Software 

Let’s first take a look how a database software program (the software) works.

There are three major tiers to the software:

  • -User Interface (UI). This is what you see when you work with the software. You interact with it. There  might be buttons, icons, text boxes, radio buttons, etc. The UI passes on clicks and typed information to the Business Logic tier.

  • -Business Logic (BL). The business logic is code that is executed to accomplish something. When a user clicks a button it will trigger the BL to run some code. The BL can send information back to the UI, so the user can see the result of clicking a button or typing something in a field. For instance when you enter something in a cell in Excel, the BL will recalculate other cells once you hit Enter and the UI will present the new information to you. The BL also needs to be able to store and retrieve data and that is handled in the Database tier.

  • -Database (DB). The database is where the data is stored and where the BL can retrieve it again.

 

1-Tier Architecture

This architecture has the UI, the BL, and the DB in one single software package. Software applications like MS Access, MS Excel, QuickBooks, and Peachtree all have the same in common: the application handles all three tiers (BL, UI, and DB). The data is stored in a file on the local computer or a shared drive. This is the simplest and cheapest of all the architectures, but also the least secure. Since users have direct access to the files, they could accidentally move, modify, or even worse, delete the file by accident or on purpose. There is also usually an issue when multiple users access the same file at the same time: In many cases only one can edit the file while others only have read-only access.

Another issue is that 1-tier software packages are not very scalable and if the amount to data gets too big, the software may be very slow or stop working.

So 1-tier architecture is simple and cheap, but usually unsecured and data can easily be lost if you are not careful.  

 

 Tier 1

 

2-Tier Architecture

This architecture is also called Client-Server architecture because of the two components: The client that runs the application and the server that handles the database back-end. The client handles the UI and the BL and the server handles the DB. When the client starts, it establishes a connection to the server and communicates as needed with the server while running the client. The client computer usually can’t see the database directly and can only access the data by starting the client. This means that the data on the server is much more secure. Now users are unable to change or delete data unless they have specific user rights to do so.

The client-server solution also allows multiple users to access the database at the same time as long as they are accessing data in different parts of the database. One other huge benefit is that the server is processing data (DB) that allows the client to work on the presentation (UI) and business logic (BL) only. This mean that the client and the server are sharing the workload and by scaling the server to be more powerful than the client, you are usually able to load many clients to the server allowing more users to work on the system at the same time and at a much greater speed.

 

 Tier 2

 

3-Tier Architecture 

In this architecture all three tiers are separated onto different computers. The UI runs on the client (what the user is working with). The BL is running on a separate server, called the business logic tier, middle tier, or service tier. Finally the DB is running on its own database server.

In the client-server solution the client was handling the UI and the BL that makes the client “thick”. A thick client means that it requires heavy traffic with the server, thus making it difficult to use over slower network connections like Internet and Wireless (4G, LTE, or Wi-Fi).

By introducing the middle tier, the client is only handling presentation logic (UI). This means that only little communication is needed between the client and the middle tier (BL) making the client “thin” or “thinner”. An example of a thin client is an Internet browser that allows you to see and provide information fast and almost with no delay.

As more users access the system a three-tier solution is more scalable than the other solution because you can add as many middle tiers (running on each own server) as needed to ensure good performance (N-tier or multiple-tier).

Security is also the best in the three-tier architecture because the middle tier protects the database tier.

There is one major drawback to the N-tier architecture and that is that the additional tiers increase the complexity and cost of the installation.

 

 Tier 3

  

 

1-Tier

2-Tier

Multi-Tier

Benefits

Very simple

Inexpensive

No server needed

Good security

More scalable

Faster execution

 

Exceptional security

Fastest execution

“Thin” client

Very scalable

Issues

Poor security

Multi user issues

More costly

More complex

“Thick” client

Very costly

Very complex

Users

Usually 1 (or a few)

2-100

50-2000 (+)

 

 

 

Comments

  • hetal(hetu.chhaiya@gmail.com) Sep 13, 2014 4:47:21 AM
    Really very useful. very simple language used. easily understandable by anyone
  • Ignorant Fool(ignorantfool@gmail.com) Aug 23, 2014 6:32:17 PM
    Good intro to the subject, thanks. Yes in the 70s and 80s, in was all 1-tier : mainframes, midrange and standalone personal computers. In the mid-90s client-server (or 2-tier) was all the rage. Later multi-tier distributed solutions started growing in popularity : application servers, distributed computing using corba, EJB etc gained popularity. However, when I pause and think about this for a moment, I am not sure I follow why a business should adopt complex multi-tier technology. For most business, in today's world, business data is stored in relational databases. So, why not go for a different kind of 2-tier solution as in : Tier1 : thin-client UI (whether web based or not is another matter) and Tier-2: All the business logic in the DB-layer itself, using stored procedures. Well, this solution is not DB-vendor independent, but is that really a huge deal ? How many DB-vendors do we have anyway ? Just support Oracle, DB2, SQLServer, MySQL and you are more or less done. Write your business logic in stored procedures conforming to ANSI standard and try to avoid any DB-vendor specific SQL-extensions. What is wrong with this kind of 2-tier approach ? Scalability ? I am sure you can scale the DB-machine accordingly. You can even keep it distributed with replicated databases etc. if your application is not database-heavy, then my approach will not work, bur for most business enterprise applications, why are businesses not choosing to go with this simple 2-tier approach I have outlined above ? Thanks - I.F
  • 5(25@gmail.co.in) Aug 22, 2014 6:36:22 AM
    4562
Add comment