Client/Server & Multi-Tier Architecture

Three jobs every data application has to do somewhere

No matter how a system is drawn, an application that talks to a database has to do three logically distinct kinds of work:

- Presentation logic — the user interface: collecting input, formatting and displaying results (a browser page, a mobile screen). - Processing (business) logic — the rules: validating input, applying business policy, deciding *what* to ask the database and *how* to combine the answers. - Storage (data) logic — actually storing, retrieving, and protecting the data: this is the DBMS.

A client/server system is a networked model that *distributes* these jobs between clients (which request services) and servers (which supply them). The single most important design decision is where each kind of logic lives, because a bad placement is expensive — drag a 100,000-row result set across a slow network to filter it on the client when the server could have filtered it first, and you have crippled performance for no reason.

Counting tiers

A tier is a separately deployable layer. The number of tiers counts the *machines/processes* the three jobs are spread across, not the three jobs themselves:

- Two-tier: a client and a single server. The database server holds storage logic; presentation lives on the client; processing logic is split between them (or pushed onto a heavy client). The classic 1990s desktop-DB application. - Three-tier: a client tier (presentation), a separate application/Web server tier (processing/business logic), and a database server tier (storage). The middle tier is the key addition. - n-tier: three-tier generalized — the middle is itself several cooperating servers (Web server, application server, integration services).

Fat vs. thin client

The fat client / thin client axis describes *how much processing the client does*:

- A fat client runs most or all of the application *and* presentation logic — it needs real processing power, and the application software must be installed and updated on every client machine. - A thin client is responsible primarily for presentation only, with the business logic on the application server. A web browser is the canonical thin client.

Thin clients win on maintenance (no software to push to thousands of machines), scalability, and reach across heterogeneous devices (phones, tablets). That is exactly why the three-tier web architecture became dominant.

Worked example: place the logic for an online registration system

A student registers for a section through a browser. Map each job to a tier:

Tier 1  Client (browser)        presentation  -> render the form, collect the section ID
Tier 2  Application/Web server   processing    -> check prerequisites, check seat availability,
                                                  build the INSERT, format the confirmation
Tier 3  Database server (DBMS)    storage       -> run the SQL, enforce constraints, return rows

Because the browser holds only presentation, it is a thin client. Because business rules sit in the middle tier — *not* baked into the page and *not* buried in the database — you can switch the DBMS from Oracle to PostgreSQL by changing the middle tier alone, scale by adding more application-server instances, and serve a phone app and a browser from the *same* business logic. Those are the benefits the exam asks you to list.

The seven benefits of three-tier (memorize for Part B Q6)

1. Scalability — the middle tier distributes load and pools database connections, so far fewer direct DB connections are needed.
2. Technological flexibility — easier to change the DBMS or move the middle tier to a different platform.
3. Lower long-term costs — off-the-shelf middle-tier components.
4. Better match to business needs — new modules can be built for a specific need without rebuilding the whole application.
5. Improved customer service — many client interfaces (browser, mobile, kiosk) reuse the same business processes.
6. Competitive advantage — small modules can be changed quickly to respond to change.
7. Reduced risk — small modules plus vendor components limit development risk.

These are *benefits with costs*: higher short-term cost, advanced tools and training, shortage of experienced staff, and immature/incompatible standards.