Q1In which tier do you put the processing that checks whether bookings overlap at the same time?
The Three-Tier Web Model — Dividing Work Across Web, Application, and Database
This article is part of the IT Foundations course, which builds up from scratch the practical IT knowledge you need at a minimum for programming and vibe coding.
Frontend and backend are other names for one of three tiers: web, application, and database. Diagrams show how a request moves across the tiers.
This article covers the three-tier web model.
It is a way of seeing a web app as three roles: web, application, and database.
The frontend and backend in beginner books are other names for one of these three.
The body text uses the full names; the diagrams are narrow, so they shorten them to Web tier, App tier, and DB tier.
The three-tier model splits one app into web, application, and database roles
The three-tier model — a structure built as three roles, web, application, and database — is the basic form of a web app, and each of the separated parts is called a tier.
| Name in this article | Formal name | What it handles | Name in beginner books |
|---|---|---|---|
| Web server tier | presentation tier | Returns the files for the screen | Frontend |
| App tier | application tier | Makes decisions and computes | Backend |
| DB tier | data tier | Stores and reads data | Database |
The user's browser runs the files returned by the web server tier and draws the screen.
The structure itself — which parts you split an app into and how you connect them — is the architecture, and the "three-tier architecture" of beginner books is the same thing as the three-tier model in this article.
my-app (members-only booking app)
Web tier (frontend)
- Shows the booking form and the list of bookings
- Takes input such as 2 people at 12/24 18:00
- Runs in the user's browser
App tier (backend)
- Checks whether 12/24 18:00 is open
- Confirms the booking and returns the result to the web server tier
- Runs on the server
DB tier (database)
- Stores booking and member records
- Reads and returns the records it is told to
- Sits on the database server
The three tiers run from top to bottom in order of how close they are to the user.
The only thing the user operates directly is the screen returned by the web server tier, and the other two stay out of sight.
The screen returned by the web server tier runs inside the browser, one per user.
With three users there are three screens, and all three share the same remaining two tiers.
The three screens on the left each run on a different computer or phone.
Of A and B, who picked the same time, the one processed second is turned down because the records are collected in a single database tier.
No matter how many screens there are, there is one destination and one set of records.
The three-tier model is a division of work inside one app
The three-tier model is a way of splitting one app into three responsibilities: web, application, and database.
The frontend of beginner books is the web server tier and the backend is the application server tier; the screen returned by the web server tier exists one per user, while a single application server tier and a single database tier are shared by everyone.
Why split into tiers — you fix one place, and you decide for everyone in one place
There are two reasons to split.
The first is that when you want to change something, the place you fix stays inside one tier.
If it is split, the only thing you touch is a file in the web server tier.
If it is all in one piece, you first search for the place that sets the color, and then re-check that unrelated processing still works.
The second is that you need a place that judges everyone's requests together and stores the result.
The screen returned by the web server tier runs in one user's browser and knows nothing about what other people entered.
The rules for those app-specific decisions are the business logic, and they go in the application server tier.
my-app (members-only booking app)
Checked on the screen
- Whether the date field was sent empty
- Whether the party size is a number
- Can warn on the spot, before sending
Rules in the App tier (business logic)
- Whether bookings overlap at 12/24 18:00
- Whether the member is over their booking limit
- Can decide after reading everyone's records
Even the screen returned by the web server tier checks things such as whether the date field is empty.
But that checking is done by a file that has reached the user's browser, so the user can rewrite it or skip it.
That is why the application server tier checks the same things again.
Take the case where two people send the same 12/24 18:00 at the same moment, and compare how the result changes depending on where you put this decision.
The difference is what is being looked at when the decision is made.
The screen side looks only at the list in its own browser, while the application server tier reads everyone's records before deciding.
With the decision on the screen side, users A and B each see only their own list, so both decide the slot is open.
With it in the application server tier, every request arrives in one place, and the records can be read and checked in order.
Splitting is about where you fix and where you decide
Split into tiers, and when you want to fix something you touch just one place.
The other reason is that you need to see and decide for everyone in one place: screens are separate per user, so they cannot tell what other people sent.
How data crosses the tiers before one booking is saved
The web server tier and the application server tier are connected by requests and responses; the application server tier and the database tier are connected by read and write instructions.
| Tier | What it does | Passes to | What it passes |
|---|---|---|---|
| Web tier | Takes the input | App tier | 12/24 18:00, 2 people |
| App tier | Checks whether it is open | DB tier | Instruction to read that day's bookings |
| DB tier | Reads the records | App tier | 0 bookings on 12/24 |
Each tier does only its own job and passes on to the next.
The web server tier never connects directly to the database tier; the application server tier always sits in between.
Once the records come back from the database tier, the application server tier decides the result.
Whichever way it splits, only one response goes back to the web server tier.
Three tiers is the basic form in this article, and real apps have exceptions.
Some setups connect straight to an external service instead of building an application server tier yourself, and in others the application server tier is split into several pieces.
Even then, you can read them by asking which of web, application, and database each part handles.
One path down and back
A user's input goes down from the web server tier to the application server tier to the database tier, and comes back the same way.
The web server tier never connects directly to the database tier; the application server tier reads the records, decides the result, and sends back a single reply.
Which part of your app is which tier — three tiers does not mean three machines
Decide first which tier each file and framework from a beginner book belongs to, and the steps start to make sense.
The web server tier is the same set of files in both cases.
What the browser can read directly is HTML, CSS, and JavaScript, so you get to choose a language only from the application server tier onward.
A tier is a way of dividing roles, not a count of computers.
Your computer
Browser (Web tier)
- Opening http://localhost:3000 shows the booking form
- Reads index.html and script.js and draws the screen
Local server (App tier)
- Started with node server.js
- Waits on port 3000 and takes requests
Database (DB tier)
- Stores booking and member records in reserve.db
- Runs inside the same computer
When you open http://localhost:3000 on your own machine, all three tiers are inside that computer.
Once you publish, the tiers are often placed on separate servers, and that work is covered in the article "Deployment and Environment Variables — From Working Locally to Going Live".
Only the screen returned by the web server tier runs on the user's device; the application server tier and the database tier are on the public server side.
Even if you move the database tier to a separate machine, the relationship stays the same: the application server tier sends it read and write instructions.
The number of tiers and the number of computers are different things
Splitting into three tiers does not mean three computers are running.
On your own machine all three sit inside your computer, and once you publish, the tiers are often placed on separate servers.
QUIZ
Knowledge Check
Answer each question one by one.
Q2What travels between the web server tier and the application server tier?
Q3You open http://localhost:3000 on your own machine and run the database on your computer as well. Where are the three tiers?