Fact: All web site architecture can be sketched as three blobs labelled “presentation”, “business logic” and “data access”. Functionality is strictly partitioned between these blobs, and they are deployed across distinct machine tiers.

OK, so this might not be true of every system, but it is a pretty common approach.

The problem is that this high-level view isn't very good at answering some very sensible questions:

Do we have to implement ALL business logic on the middle tier? Surely it is more efficient to stick it close to the presentation process? Why are we taking a performance hit to go through the middle tier to access the database? What about putting business logic in stored procedures?

Rather than sticking with the (admittedly short) description above, I like to think of 3-tier as a collision of a few patterns:

Scale out - So why don’t we use one big machine? Scaling out allows us to increase our non-database processing linearly with cost. We offload as much processing as possible to this cheap processing resource, and try to minimise the usage of our expensive scale-up database resource. This also gives us cheap fault tolerance across our scale-out machines.

N-layer logical architecture – Layering is a fundamental organising principle of software. In this case, the crucial distinction is that logical separation doesn’t imply physical separation.

Remote application tier – Lastly, a security pattern. If we are already scaling out our non-database functionality, why partition our processing again between web and application servers? The web is a hostile place, and the remote application tier is an attempt to put as much distance as possible between our sensitive data and the web. So by partitioning a web application into several physical tiers, we can put multiple firewalls in place to protect that sensitive data.