A company is designing a three-tier web application with browser clients, an application tier and a database tier. A developer proposes letting the browser-side code connect straight to the database to save a hop. Why does the client/server design keep the database separate behind the application tier?

In a client/server, multitier architecture, each tier has a defined role. Browser clients send requests to the application tier, which authenticates users, applies business rules, validates input and issues parameterized queries to the database using its own service credentials over a protected network path. The database tier accepts connections only from the application tier, not from the internet. This minimizes the attack surface, keeps credentials off client devices, centralizes authorization and lets each tier scale independently. Direct browser connections would expose database ports and credentials to anyone who can inspect the client code. Claiming that clients need direct connections to call stored procedures is false; the application tier calls stored procedures on the client's behalf and does not block them. Making the web tier the authoritative data store contradicts the design, since the database remains the system of record and the web tier may cache but should not own data. Insisting the database must share a host with the web server ignores that separating tiers is standard practice and that the small network latency is outweighed by security, scalability and manageability. Exam caveat: two-tier client/server designs with direct database connections still exist on trusted internal networks. Operational check: confirm the database firewall accepts connections only from application-tier addresses.