What it is
The three tier architecture splits a web system into three layers that can scale and evolve on their own.
- Presentation tier renders the UI in the browser and talks only to the application tier.
- Application tier holds business logic, validation, and orchestration. It is stateless when done well.
- Data tier persists state in databases, caches, and object stores.
Why separate them
- Each tier can scale independently. A read heavy app adds web nodes without touching the database.
- Failures stay contained. A crash in app logic does not corrupt the browser session directly.
- Teams own clear boundaries with well defined contracts between layers.
How requests flow
The browser never reaches the database directly. Every request passes through the application tier, which enforces rules and shapes data before returning it.
Practical notes
- Keep the application tier stateless so any node can serve any request.
- Push session and cached data into the data tier, not into app memory.
- The boundary between tiers is where you add load balancers and caches.
Key idea
Three tiers give you independent scaling and clear contracts by keeping presentation, logic, and data strictly apart.