Core CS · DBMS
One query, three architectures
A tier is a machine boundary, not a folder in your code. Count the boundaries between the user and the rows.
Send one request through 2-tier, then 3-tier →01 The idea
A tier is a machine boundary
You can write a program with a user-interface layer, a service layer and a data layer, compile all three into one file, and run it on a laptop. That is three layers and one tier. Layers are how you organise code. Tiers are where that code runs, and a tier boundary means the two sides talk over a network.
Four jobs exist in every database application, whatever the architecture. Something draws the screen and takes the click. Something decides what is allowed: may this student see these marks, is the deadline past, is this refund approved. Something opens a connection and sends SQL. Something stores the rows and finds them again. Architecture is only the question of how many machines you spread those four jobs across, and where exactly you cut.
02 Worked example
One query, and the places you can cut it
Results day. Student S1 opens My Marks, and exactly one query has to run: SELECT subject, marks FROM result WHERE sid = 'S1'. It returns five rows. That SQL is identical in all three architectures — the database cannot tell them apart. What differs is which machine each of the four jobs runs on. Here are the four jobs in order, with the one whose position decides everything else highlighted.
Cut nowhere and you have 1-tier. All four boxes are one program on one machine. S1 clicks, and the same process that drew the button opens a file on the local disk and reads five rows out of it. Zero network round trips, so nothing is faster. There is also no connection string, no username and no password, because nothing is being connected to. The catch is the thing that makes it simple: a second person on a second machine cannot see those rows at all.
Cut once, between data access and storage, and you have 2-tier. The database moves to its own machine. The program on the laptop still decides what is allowed and still writes the SQL, then sends it over a JDBC or ODBC connection it opened using a host, a port, a username and a password. One round trip per query. Two consequences follow immediately, and they are the whole case against 2-tier: the laptop has to store a working database login, and the check may S1 see these marks runs on a machine the student owns.
Cut twice, after presentation and after data access, and you have 3-tier. The browser sends an HTTP request carrying a session cookie and nothing else — no host name, no password, no SQL. An application server reads that cookie, works out that this session belongs to S1, writes the query with sid bound to S1, and borrows one of its already-open database connections. Two round trips instead of one. In exchange the database credential exists in exactly one place, and the rule that S1 reads only S1’s marks runs where the student cannot reach it.
The SQL never changed. The cut moved. Every difference in the next section is a consequence of where the cut falls, because a cut is three things at once: a network hop you have to pay for, a place a credential has to live, and a machine you can add more of.
03 Mechanics
Three architectures, seven properties that differ
Read this table down a column, not across a row. Each column is a coherent set of trade-offs, and the numbers assume the same scenario throughout: 200 students, one query per page, a PostgreSQL server left on its default settings.
| Property | 1-tier | 2-tier | 3-tier |
|---|---|---|---|
| Machines between user and rows | 1 | 2 | 3 |
| Network round trips per query | 0 | 1 | 2, and one of them is on the LAN |
| Where the database login lives | there is no login | on every client machine | on the app server only |
| Connections at 200 users | not applicable, one user | 200 asked for, 100 allowed | 20 pooled |
| “May S1 see this?” is decided | in the same process as the UI | on the user’s machine | on a machine you control |
| Changing one business rule | reinstall on that one machine | reinstall every client | deploy once |
| What you run out of first | users, at exactly one | database connections | app servers, so add more |
Two rows deserve a second look. Connections is the one that surprises people: a database connection is not free. PostgreSQL gives each connection its own server process and defaults max_connections to 100; MySQL uses a thread per connection and defaults to 151. A 2-tier client holds its connection for as long as the application is open, whether or not anyone is querying, so 200 running copies means 200 connections sitting there. A pool in the middle needs one connection per query that is running right now, which is a far smaller number.
Round trips is the row that keeps 3-tier honest. It really does add a hop, and you should say so in an interview before anyone asks. The reason it usually does not hurt is that the added hop is between two machines in the same rack, while the hop it saves you is across the user’s internet connection. A page needing several queries pays for the slow link once instead of once per query.
05 Cheat sheet
Four architectures on one card
| Architecture | Machines | Business logic runs on | What it costs you |
|---|---|---|---|
| 1-tier | 1 | the same process as the UI | one user, one machine |
| 2-tier | 2 | the client, or stored procedures | a DB login on every client |
| 3-tier | 3 | a dedicated application server | one extra network hop |
| n-tier | 4 or more | several specialised services | one more hop per split |
06 Where & why
Where each tier count actually lives
None of these three is obsolete and none is a beginner version of the next. Each is the right answer for a particular shape of problem, and you can point at software on your own machine running every one of them right now.
SQLite is a library, not a server. It runs inside your application’s own process and reads a file on the same disk, which is why phone apps, browsers and desktop tools use it for local data. No port, no connection string, no login, and no second user.
You type a host, a port, a username and a password into MySQL Workbench, or into an Oracle Forms client, and it connects straight to the database. That is exactly the right shape for a few trusted staff on one office network, and exactly the wrong shape the moment a client sits outside it.
Browser, application server, database server. The browser holds a session cookie; the PostgreSQL password sits only in the application server’s environment. Every request is re-authorised on the server, which is why editing the student ID in a URL does not fetch somebody else’s marks.
NGINX balancing the load, Redis caching beside the application server, Elasticsearch owning search. The counting rule has not changed: trace one request, count the machines it touches on the way to the rows. Split when one piece needs to scale or ship on its own schedule, not because the diagram looks more serious with more boxes.
07 Interview questions
What they actually ask
This topic opens a lot of DBMS interviews because it is easy to ask and easy to answer badly. The failure mode is reciting three definitions with no consequence attached. Attach the consequence every time: credentials, connections, deployment, hops.
What is a tier, exactly?
Describe 1-tier architecture and give a real example.
What changes when you move to 2-tier?
In 3-tier, where does the business logic run and why does that matter?
Give the security argument for 3-tier in one sentence.
Two hundred users open a 2-tier application at the same time. What happens?
What is a connection pool, and why is it a 3-tier idea?
Does the extra tier make the application slower?
Is 3-tier the same thing as MVC?
What is n-tier, and when do you actually need it?
When would you still choose 2-tier today?
08 Practice problems
Six to work through
For each one, write the list of machines first. Almost every wrong answer in this topic comes from counting layers of code, or counting clients, instead of counting machine boundaries between the user and the rows.