Presentation, Logic, and Data Tiers

Once a client and a server can exchange HTTP requests, the next question is where things live. A small project often runs as a single program that draws the screen, applies the rules and talks to the database all at once, and that is a perfectly good way to start. The trouble comes as it grows: changing the color of a button should not risk breaking billing, and a rush of shoppers should not force you to copy your entire application just because one part of it is busy. Almost every application, from a side project to a huge social network, solves this the same way, by splitting itself into three layers called tiers. This chapter explains what each tier is for, and why the split is the starting point for nearly everything else in the course.

Think of a hotel. The front desk is where guests ask for things: a room, a late checkout, a wake-up call. The manager decides whether the answer is yes: is a room free, is this guest allowed to extend their stay, does the corporate discount apply. And the reservation ledger in the back office is where the facts are written down, so that they survive a shift change, a power cut or a new manager. Each has a different job, and the arrangement only works because they stay separate. The front desk does not make policy, the manager does not keep the only copy of the bookings in their head, and the ledger does not decide anything: it simply remembers.

• -The front desk is the presentation tier: what the user sees and touches, such as a browser page or a mobile screen. Its job is to show information and collect requests, not to decide anything.
• -The manager is the logic tier (also called the application tier): the servers that apply the business rules, such as can this user afford this item, or is this password correct.
• -The ledger is the data tier: the database that stores facts durably, so they outlive any single request and any server restart.

In a diagram, a request flows down through the tiers and the answer flows back up:

Follow one purchase, a customer buying two of item 42:

• -Presentation: the page shows the item and the customer taps Buy. The browser sends: item 42, quantity 2.
• -Logic: the server checks the customer is logged in, looks up the real price, confirms there is stock, applies any discount code, and decides whether the order is allowed.
• -Data: the server asks the database to reduce the stock by 2 and record the order. The database does exactly that and reports back; it does not question the decision.
• -Logic: the server builds a confirmation out of what the database returned.
• -Presentation: the page shows Order confirmed.

Now ask where a rule like no more than 5 of an item per customer belongs. Not in the presentation tier: anyone can bypass a browser, as the last module showed. It belongs in the logic tier, the one layer you fully control and which can see everything it needs to decide. The data tier can enforce simple integrity rules, for example that a stock count never drops below zero, but business rules change often and need context, so they live above it.

The payoff is independence. You can redesign the screens without touching a single business rule. You can change the database engine without rewriting the screens. And, most importantly for this course, each tier can scale on its own schedule, driven by its own bottleneck: a flash sale might need ten times as many logic servers while the database needs nothing new.

Scaling separately does not mean any tier can be ignored, because every request passes through all of them. Here is a throughput example with made-up but realistic round numbers. Suppose each logic server handles 500 requests per second and you run 10 of them, so the logic tier can take 5,000 requests per second. Each request makes 4 database queries, and the database can answer 5,000 queries per second. Divide: 5,000 queries a second at 4 per request supports only 1,250 requests a second. Add more logic servers and nothing improves, because the database is the bottleneck. A chain is only as strong as its weakest link, and a system is only as fast as its slowest tier.