Episode 1 — Fundamentals / 1.2 — Client Server Architecture

1.2.a - What is the Client-Server Model

1. Definition

Client-server architecture is a distributed computing model in which work is split between two main roles:

Clients initiate communication and request services (data, computation, or resources).
Servers wait for those requests and provide the services—often persistently and to many clients at once.

The client and server are usually separate programs or processes, and they may run on different machines connected by a network. The model is not tied to a single technology: the “client” can be a browser, a phone app, or a command-line tool; the “server” can be a web server, an API, a game host, or a database process.

In short: clients ask; servers answer (and enforce rules, store authoritative data, and scale that work centrally).

2. History

Mainframe and terminals

Early systems often used a mainframe (powerful central computer) with dumb terminals: screens and keyboards with almost no local processing. Users typed commands; the mainframe did all computation and storage. This was highly centralized but expensive and inflexible for personal computing.

Rise of personal computers and LANs

As PCs and local area networks (LANs) spread, organizations wanted to share files, printers, and applications without giving every user a mainframe session. File servers and database servers on the LAN became common: PCs ran richer client software while servers held shared data.

Internet-era client-server

The web generalized the pattern globally: the browser is the client; HTTP servers (and layers behind them) are servers. Mobile apps and cloud APIs extended the same idea: thin or thick clients talking to remote services over TCP/IP, often with multi-tier backends (application + database + caches, etc.).

Evolution in one line: from “one big brain, many keyboards” → “smart devices requesting services from specialized, shared backends over a network.”

3. Core Components

Client

What it is

Web: Browsers (Chrome, Firefox, Safari, Edge).
Mobile: Native or hybrid apps (iOS/Android).
Desktop: Electron apps, native GUIs, or developer tools.
CLI: Programs like curl, database clients, or deployment CLIs that call APIs.

What it does

Sends requests (HTTP, WebSockets, gRPC, proprietary game protocols, etc.).
Presents the user interface and handles input (clicks, forms, gestures).
Renders or displays results (HTML/CSS, JSON → UI, video frames, game state).
May run some logic locally (validation, caching, offline behavior)—but authoritative business rules and shared data usually live on the server side.

Server

What it is

Web / API server: nginx, Apache, or app frameworks (Express, Django, Spring, etc.).
Application server: Runs business logic, orchestrates workflows, talks to other services.
Database server: PostgreSQL, MySQL, MongoDB, etc.—stores and queries structured data.
Specialized servers: Mail (SMTP/IMAP), game matchmaking, media streaming origins, etc.

What it does

Listens for incoming connections or requests.
Authenticates and authorizes (who is this? what may they do?).
Executes business logic (pricing, permissions, workflows).
Reads and writes persistent data (often via a database or object store).
Returns responses (HTML, JSON, binary payloads, streams).

Network

The network is the communication channel—typically packet-switched infrastructure (e.g., Ethernet, Wi‑Fi, cellular, the public Internet). Protocols such as TCP/IP, HTTP/HTTPS, DNS, and TLS define how requests are addressed, routed, secured, and delivered.

Without a working network path (or with high latency/loss), the client cannot reach the server reliably—so availability and performance depend on both software and connectivity.

4. How It Works

Typical request–response flow:

The client builds and sends a request (URL, method, headers, body).
The server receives the request, parses it, and processes it (auth, validation, business rules, database access).
The server sends a response (status, headers, body—HTML, JSON, file bytes, etc.).
The client handles the response—renders a page, updates state, plays media, or shows an error.

ASCII diagram: request–response

+----------+                      +----------+
|  CLIENT  |                      |  SERVER  |
| (browser |   1. Request         | (listens |
|  or app) | ------------------>  |  & runs  |
|          |      HTTP/TLS        |  logic)  |
|          |   2. Response        |          |
|          | <------------------  |          |
+----------+                      +----------+
     |                                   |
     | 3. Render UI / update app state    |
     v                                   |
  User sees result                        |

Example: conceptual HTTP exchange

Client → Server (request):

GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer <token>

Server → Client (response):

HTTP/1.1 200 OK
Content-Type: application/json

{"id":42,"name":"Ada","role":"engineer"}

The client then maps that JSON into UI elements or application state.

5. Types of Client-Server Architecture

1-Tier (all on one machine)

Everything—UI, application logic, and data—runs on a single system (e.g., a desktop app with an embedded database). There is still a logical separation between “presentation” and “data” in the code, but no network is required between client and server processes.

Use when: offline-first tools, embedded systems, or simple local apps.

+---------------------------+
|  One machine              |
|  [ UI + Logic + DB ]      |
+---------------------------+

2-Tier (client + server)

The client handles presentation (and some logic); the server provides data and core services—often a database-backed API or a classic “thick client + DB server” setup.

+--------+          +--------+
| Client | <------> | Server |
|        |  network | (e.g.  |
+--------+          |  DB)   |
                    +--------+

3-Tier (client + application server + database) — most common

The client talks to an application server (business logic, APIs). The application server talks to a database server (persistence). This separates concerns: the DB is not exposed directly to every client; scaling and security are easier.

+--------+       +-------------+       +----------+
| Client | <---> | App server  | <---> | Database |
|        |       | (API/logic) |       |  server  |
+--------+       +-------------+       +----------+

N-Tier / microservices

N-tier generalizes 3-tier: multiple layers or services—gateways, auth, billing, search, notifications—each potentially its own server (or fleet). Microservices push this further: many small, independently deployable services behind APIs and message queues, often with load balancers and service discovery.

                         +----------------+
                         |  API Gateway   |
                         +--------+-------+
                                  |
        +------------+------------+------------+
        |            |            |            |
   +----+----+  +----+----+  +----+----+  +----+----+
   | Service |  | Service |  | Service |  |   DB    |
   |    A    |  |    B    |  |    C    |  | cluster |
   +---------+  +---------+  +---------+  +---------+

6. Client-Server vs Peer-to-Peer

Aspect	Client-Server	Peer-to-Peer (P2P)
Roles	Asymmetric: dedicated servers serve many clients	Symmetric (in principle): peers both consume and provide
Control / data	Centralized or federated around servers	Distributed across peers
Discovery	Clients know server addresses (DNS, config)	Peers must find each other (DHT, trackers, local discovery)
Scalability	Scale servers (replicas, sharding, CDNs)	Scale participation; can offload bandwidth to peers
Consistency	Easier to enforce one “source of truth” on servers	Harder; conflict resolution and trust vary by design
Failure modes	Server outage can affect all clients	Network partitions; unreliable individual peers
Examples	Web apps, most mobile backends, email via provider	BitTorrent, some VoIP/gaming topologies, blockchain nodes

Many real systems are hybrid: e.g., a game uses client-server for authoritative state but P2P or relays for voice chat.

7. Real-World Examples

Web browsing

The browser (client) requests HTML, CSS, JS, and assets via HTTP(S) from web servers and CDNs; servers return documents and cache headers; the browser renders the page and runs scripts—which may trigger more requests (API calls, images).

Email (SMTP / IMAP)

SMTP clients (or other mail servers) submit outgoing mail to an SMTP server; IMAP/POP clients fetch mail from a mailbox server. The “server” role is specialized and often split across several machines (ingress, storage, spam filters).

Online gaming

The game client sends player input to a game server (or match-hosted session); the server simulates or authorizes game state and broadcasts updates. This reduces cheating compared to fully client-authoritative designs.

Streaming

Clients request manifests and media segments (e.g., HLS/DASH) from origin or CDN servers; the client buffers and decodes video/audio locally. Heavy lifting for encoding happens server-side; playback is client-side.

8. Advantages

Centralized data: One authoritative store (with backups and replication) simplifies consistency and reporting.
Scalability: Scale out stateless app servers, add read replicas, caches, and CDNs while clients stay thin.
Security: Sensitive logic and secrets stay on the server; clients get only what they need (tokens, limited data).
Easier maintenance: Update server code or content once; many clients benefit without reinstalling (especially for web).
Operational visibility: Logging, metrics, and rate limiting concentrate where requests arrive.

9. Disadvantages

Single point of failure: If the critical server or region is down, clients may be unable to work (mitigated by redundancy, failover, multi-region design).
Server overload: Traffic spikes can exhaust CPU, memory, or connection limits unless you scale and protect with queues, autoscaling, and caching.
Network dependency: Latency, outages, and captive portals directly impact user experience; offline use requires extra client design.
Cost and complexity: Running reliable 24/7 infrastructure (monitoring, patching, compliance) is non-trivial at scale.

10. Key Takeaways

Client-server is a request–response pattern: clients request services; servers provide them over a network.
Clients focus on interaction and presentation; servers focus on logic, policy, and persistent data—though the exact split varies by app.
3-tier (client → app server → database) is the most common shape for web and mobile backends because it isolates the database and supports scaling each tier.
Compared to P2P, client-server trades central control and simpler consistency for dependency on servers and the network.
Real systems combine architecture tiers, caching, and CDNs—the model is a mental framework, not a single diagram.

11. Explain-It Challenge

Prompt (try without looking up): In your own words, walk through what happens when someone opens a social feed on their phone—from tapping the app icon to seeing new posts. For each step, say whether the work is happening on the client, the application server, the database, or the network, and why that division matters for security and scale.

Stretch goal: Draw a 3-tier ASCII diagram for that scenario and label one request and one response payload type (e.g., JSON list of posts).

Next: 1.2.b - Client vs Server