Take the 2-minute tour ×

In a traditional sense, N-tier means separating the application into "tiers" and putting each "tier" on different servers. This was done for at least 3 reasons:

  1. Maintenance:

    a) Code Maintenance: Easier to do bug fixes and feature additions.

    b) Hardware Maintenance: Taking one server down does not disrupt service from other tier.

  2. Performance: One server was often not fast enough to handle web requests, business logic computations, and database/file access at the same time.

  3. Scalability: Specifically horizontal scalability

    a) Fault Tolerance: Ability to have more than 1 physical server per tier means when 1 server is down, the application can still function as a whole.

    b) Load-balancing: Having multiple instances of a tier helps service large amount of requests.

Nowadays, hardware and networks are fast enough to serve thousands of requests per second on a single server. Also, the buzz word for IT right now is "consolidation". So even if the application is split into tiers, they probably will end up hosting on virtual machines on a single server.

I think nowadays when people talk about N-tier architecture, they are talking about separation of concerns within the application. It is more of a logic separation than a physical one. I think as long as we achieve good separation of concerns and loose coupling, applications do not have to be N-tier. It just seems that many programmers think that N-tier architecture is a golden standard that every web application must comply with.

So, what is N-tier architecture to you nowadays?

share|improve this question
add comment

3 Answers

From wikipedia article I read:




But to conclude, I think a programmer should only think abuot layers and separation of concerns within the application to achieve the most important (and difficult) task: maintainability in the long run.

share|improve this answer
Agree. I guess managers/upper managements/interviewers like to use the word 'N-tier' because it is proven that N-tier provides maintainability, performance, and scalability if done right. But it should be viewed the other way around. Also, I think of this article every time talking about scalability. –  Thomas Li Sep 1 '11 at 14:37
+1 - Layers are logical, Tiers are physical. Both concepts are still very relevant and shouldn't be confused. –  Adrian K Sep 2 '11 at 0:09
add comment

I think it is, and always has been, an artificial distinction. I agree with your premise that it refers mostly to logical separation of components these days. However, there are still plenty of applications that are too big (use wise or data-wise) to fit on a single machine, so the idea of separating an application into discrete components for scalability reasons is definitely not dead.

share|improve this answer
Agree. Separating into discrete components for scalability reasons is not dead yet but faster hardware and network and server consolidation definitely pushes down the number of applications that need to do this. –  Thomas Li Sep 1 '11 at 14:04
It is probably not dead, but for example in the case of websites there are more effective ways to handle more page views. –  Durden81 Sep 1 '11 at 14:13
add comment

Security for one? I'd rather you hit my web servers than my app servers!

share|improve this answer
add comment

Your Answer


