Presentation, Logic, and Data Tiers
You'll learn to
- -Name the three tiers and what each is responsible for
- -Explain why separating tiers makes a system easier to scale and maintain
Once you have a client and a server exchanging HTTP requests, the very next question is: where does the data live? Almost every application (from the smallest side project to the largest social network) starts from the same three-tier shape, splitting responsibility into three layers.
The three tiers: presentation, logic, and data.
- -Presentation tier: what the user sees and interacts with, such as a browser or a mobile app.
- -Logic tier: the application server that enforces business rules, like "can this user afford this item" or "is this password correct."
- -Data tier: durable storage, a database that outlives any single request and any single server restart.
The reason this split matters is independence: you can change how the app looks (presentation) without touching business rules (logic), and you can scale your web servers (logic) without needing more copies of your database (data); each tier grows on its own schedule, driven by its own bottleneck.
The three-tier model has one landmine baked in from the start: the data tier is usually a single database, which becomes both a single point of failure and the hardest tier to scale. Nearly every topic for the rest of this course is, in one way or another, about relieving pressure on that one box.
Why not just put everything (UI logic, business rules, and data access) in one program?
"Separation of concerns is a best practice."
"Because each tier fails and scales differently. A traffic spike means I need more web servers, not more database copies. A schema change shouldn't require redeploying the UI. And if the data tier is compromised, the presentation tier being a separate, dumber layer limits the blast radius. Coupling them means every change (and every failure) has to be reasoned about across the whole system instead of one tier at a time."