Server-side Java: Counting tiers - one, two, or n?

How many tiers does your application architecture need?

I hate articles that make you wade through mountains of text before getting to the point. Accordingly, here is a chart summarizing the pros and cons of different architectures for distributed applications discussed in this article.

On tiers

In the beginning, life was simple. Computers were separate, individual devices. Programs had access to all the computer's input and output through computer-connected devices. With the invention of networks, life became more complicated. Now we have to write programs that depend on other programs running on faraway computers. Often, we have to write all those faraway programs as well! This is what's called distributed programming.

A brief definition: a distributed application is a system comprised of programs running on multiple host computers. The architecture of this distributed application is a sketch of the different programs, describing which programs are running on which hosts, what their responsibilities are, and what protocols determine the ways in which different parts of the system talk to one another.

One tier


Very high performance


No networking -- can't access remote services

Potential for spaghetti code

Two tiers

Clean, modular design

Less network traffic

Secure algorithms

Can separate UI from business logic

Must design/implement protocol

Must design/implement reliable data storage

Three tiers

Can separate UI, logic, and storage

Reliable, replicable data

Concurrent data access via transactions

Efficient data access

Need to buy database product

Need to hire DBA

Need to learn new language (SQL)

Object-relational mapping is difficult

N tiers

Support multiple applications more easily

Common protocol/API

Quite inefficient

Must learn API (CORBA, RMI, etc.)

Expensive products

More complex; thus, more potential for bugs

Harder to balance loads

The concept of tiers provides a convenient way to group different classes of architecture. Basically, if your application is running on a single computer, it has a one-tier architecture. If your application is running on two computers -- for instance, a typical Web CGI application that runs on a Web browser (client) and a Web server -- then it has two tiers. In a two-tier system, you have a client program and a server program. The main difference between the two is that the server responds to requests from many different clients, while the clients usually initiate the requests for information from a single server.

A three-tier application adds a third program to the mix, usually a database, in which the server stores its data. The three-tier application is an incremental improvement to the two-tier architecture. The flow of information is still essentially linear: a request comes from the client to the server; the server requests or stores data in the database; the database returns information to the server; the server returns information back to the client.

An n-tier architecture, on the other hand, allows an unlimited number of programs to run simultaneously, send information to one another, use different protocols to communicate, and interact concurrently. This allows for a much more powerful application, providing many different services to many different clients.

It also opens a huge can of worms, creating new problems in design, implementation, and performance. Many technologies exist that help contain this nightmare of complexity, including CORBA, EJB, DCOM, and RMI, and many products based on these technologies are being furiously marketed. However, the leap from three-tier to n-tier -- or the leap from one- to two-tier, or from two- to three-tier, for that matter -- must not be taken lightly. It's easy to open a can of worms, but you always need a bigger can to put them back in. The proponents of these technologies are infatuated with their advantages, and often fail to mention the disadvantages of jumping to a more complicated architecture.

In this article, I will discuss the advantages and disadvantages of each style of architecture, and give you some information that will help you choose the right architecture for your application. Consider these reasons before choosing a product because its fact sheet promises to make your life easier.

1 2 3 4 Page 1
Page 1 of 4
How to choose a low-code development platform