Why this matters
YouTube, Amazon and Gmail look nothing alike, but they are built the same way. Once you can see the three tiers behind a screen, almost every online service stops being a mystery and becomes a variation on one pattern.
The idea
A web application is an application you use through a browser, with nothing to install. It is built from three tiers:
| Tier | Role | Examples |
|---|---|---|
| Frontend | The screen the user sees and types into, running in the browser | Search box, product listings, forms |
| Backend | Server-side processing the user never sees; handles data and decides things | Searching for matching products, checking a login |
| Database | Organises, stores and manages the data | Product info, user accounts, order history |
They cooperate on every action. Searching an online shop runs like this: the frontend takes the keywords and sends them to the backend; the backend queries the database; the database returns the matching rows; the backend arranges them into results; the frontend puts them on screen. A request travels down the tiers and an answer comes back up.
The useful thing about three-tier architecture is how little changes between services. A video site, a social network and a shop all use the same three tiers; what differs is only what each tier holds:
| Service | Frontend | Backend | Database |
|---|---|---|---|
| Video sharing | Player and search screens | Picking recommendations, counting views | Videos, users, watch history |
| Social network | Timeline and post screens | Deciding who sees a post, push notifications | Posts, follows, messages |
| E-commerce | Product lists and cart | Stock checks, payment | Products, orders, customers |
Picture it
sequenceDiagram participant U as User participant F as Frontend participant B as Backend participant D as Database U->>F: types search keywords F->>B: sends the keywords B->>D: queries for matching products D-->>B: returns matching rows B-->>F: returns organised results F-->>U: displays the results
Worked example
Why can the frontend not just read the database itself and skip the middle tier?
Because the frontend runs on the user's own machine, inside a browser they fully control. Anything it can reach, they can reach. A frontend holding database credentials hands every visitor the keys to every other customer's order history, and nothing stops them asking for rows that are not theirs.
The backend exists to be the part the user cannot tamper with. It is where "you may see your own orders and nobody else's" is enforced, where the password is checked, where stock is decremented exactly once. The database tier is separate again because storing data reliably is its own hard job: indexes, backups, surviving a restart.
So the split is not decoration. Each tier is where a different guarantee lives: presentation, rules, and durable storage.
Your turn
Try the practice questions for this lesson. Judge statements about what each tier does, match each description to its tier, and work out which tier answers a given part of a search.
Take it further
A clinic wants a web app where patients book appointments, see which slots are free, and view past visits. Should it put everything in one place, or separate the three tiers?
- Assign the work. For the booking form, checking which slots are free, and storing past visits, say which tier should handle each and why.
- Diagnose a fault. The booking page opens normally but no free slots appear. Which tier is clearly working, and which has probably failed?
- Decide. Recommend whether to separate the app into three tiers, and give two reasons.
For step 2, ask what had to succeed for you to be looking at the page at all.
Recap
- A web application runs in a browser with nothing to install.
- Frontend shows and collects, backend processes and decides, database stores.
- A request goes frontend to backend to database, and the answer comes back the same way.
- Every familiar service uses the same three-tier architecture; only the contents change.