Three Tier Architecture

Definition

Three-Tier Architecture inserts a middle Application/Business-Logic tier between the client and the database, producing three layers: Tier 1 (presentation/client) — a "thin client" with UI only; Tier 2 (application server) — holds business logic and typically manages a shared pool of database connections; Tier 3 (database server) — stores and serves data only.

How It Works — Logic Moves Off the Client

A student uses a college's web portal. The browser (Tier 1, thin client) sends a request to a web/application server (Tier 2), which runs the "compute final grade" business logic and then queries the database server (Tier 3) — typically reusing one of a small set of pooled connections rather than opening a new one per user. The computed result flows back up through Tier 2 to the browser.

Contrast With Two-Tier (2.9)

The business logic that lived on every individual client in two-tier architecture is moved off the client and into the middle tier. This means: (1) updating a business rule requires changing the application server once, not redeploying software to every client machine, and (2) the middle tier can pool and share database connections across many simultaneous users instead of requiring one dedicated connection per client — directly solving the two-tier connection-scaling bottleneck.

Edge Cases and Pitfalls

• The application server itself can become a new bottleneck or single point of failure — this is typically mitigated by running multiple load-balanced app-server instances rather than just one.
• Adding a middle tier introduces an extra network hop between client and database (client → app server → database), which can add latency compared to a direct two-tier connection, even though it usually pays for itself in scalability and maintainability.
• A common misconception is that three-tier architecture eliminates the database server's importance — in fact, Tier 3 still fully owns data storage and integrity; only the business logic and connection management have moved.

Interview Takeaways

• Q: Why is three-tier generally preferred for large web applications over two-tier? It centralizes business logic for easier maintenance, enables connection pooling at the middle tier for better scalability, and allows each tier to be scaled independently (e.g., adding more app servers without touching the database tier).
• Q: What is Tier 1 typically called in three-tier architecture, and why? A "thin client," because it contains only the presentation/UI layer, with no embedded business logic.