What is the Client-Server Model?

The client-server model is a distributed computing architecture where work is divided between two roles:

• Client: The entity that initiates requests. This is typically a web browser, mobile app, or another service that needs data or processing.
• Server: The entity that listens for requests, processes them, and returns responses. This could be a web server, application server, or database server.

This is a request-response model: the client asks, the server answers. The server does not spontaneously push data to the client (that requires different patterns like WebSockets, which we cover in a later lesson).

A Simple Analogy

Think of a restaurant. You (the client) place an order with the waiter. The kitchen (the server) prepares the food and sends it back through the waiter. You do not walk into the kitchen yourself, and the kitchen does not start cooking for you until you order.

Key Characteristics

How HTTP Works

HTTP (HyperText Transfer Protocol) is the application-layer protocol that clients and servers use to communicate on the web. It runs on top of TCP (Transmission Control Protocol), which guarantees reliable, ordered delivery of data.

The Request-Response Cycle

Client                              Server
  |                                    |
  |  1. TCP Handshake (SYN/SYN-ACK)    |
  |----------------------------------->|
  |<-----------------------------------|
  |                                    |
  |  2. HTTP Request                   |
  |  GET /api/users HTTP/1.1           |
  |  Host: api.example.com             |
  |  Accept: application/json          |
  |----------------------------------->|
  |                                    |
  |  3. Server processes request       |
  |     (query DB, run logic, etc.)    |
  |                                    |
  |  4. HTTP Response                  |
  |  HTTP/1.1 200 OK                   |
  |  Content-Type: application/json    |
  |  {"users": [...]}                  |
  |<-----------------------------------|
  |                                    |

HTTP Methods

HTTP defines several methods (also called verbs) that indicate the intended action:

Idempotent means making the same request multiple times produces the same result. GET /users/42 always returns user 42. DELETE /users/42 deletes user 42 the first time; subsequent calls are no-ops.

Safe means the request does not modify server state. GET and HEAD are safe; POST and DELETE are not.

HTTP Status Codes

Status codes tell the client what happened:

HTTP Headers

Headers carry metadata about the request or response:

• Content-Type: What format the body is in (e.g., application/json, text/html)
• Authorization: Authentication credentials (e.g., Bearer <token>)
• Cache-Control: Caching directives (e.g., max-age=3600, no-cache)
• Accept: What formats the client can handle
• User-Agent: Identifies the client software
• Set-Cookie / Cookie: Session management

HTTPS and TLS Encryption

HTTPS is HTTP over TLS (Transport Layer Security). It provides three critical security properties:

1. Encryption: Data is encrypted in transit, so eavesdroppers cannot read it.
2. Integrity: Data cannot be tampered with without detection (via MAC - Message Authentication Code).
3. Authentication: The server proves its identity via a digital certificate, preventing impersonation.

The TLS Handshake (Simplified)

Client                                   Server
  |                                         |
  |  1. ClientHello                         |
  |  (supported cipher suites, TLS version) |
  |---------------------------------------->|
  |                                         |
  |  2. ServerHello + Certificate           |
  |  (chosen cipher suite, server's cert)   |
  |<----------------------------------------|
  |                                         |
  |  3. Client verifies certificate         |
  |     (checks CA signature, expiry, etc.) |
  |                                         |
  |  4. Key Exchange                        |
  |  (both derive shared session key)       |
  |<--------------------------------------->|
  |                                         |
  |  5. Encrypted HTTP traffic begins       |
  |<========================================>|

Why HTTPS Matters in System Design

• All production traffic should use HTTPS. Google Chrome marks HTTP sites as "Not Secure."
• TLS termination can happen at the load balancer or reverse proxy, reducing overhead on application servers.
• Certificate management (via services like AWS Certificate Manager or Let's Encrypt) is a real operational concern.
• TLS adds latency due to the handshake (1-2 extra round trips in TLS 1.2, reduced to 1 in TLS 1.3).

HTTP vs HTTPS

Full Request Lifecycle

When you type https://www.example.com/api/data in your browser, here is everything that happens:

Step-by-Step Breakdown

1. DNS Resolution: The browser resolves www.example.com to an IP address (e.g., 93.184.216.34). This involves checking the browser cache, OS cache, and potentially querying DNS servers recursively. (We cover DNS in depth in the next lesson.)

2. TCP Connection: The browser opens a TCP connection to the server's IP on port 443. This requires a 3-way handshake (SYN, SYN-ACK, ACK).

3. TLS Handshake: Since this is HTTPS, the client and server negotiate encryption parameters and exchange keys.

4. HTTP Request: The browser sends the HTTP request over the encrypted channel.

5. Server Processing: The server receives the request, routes it to the appropriate handler, executes business logic (database queries, computations), and constructs a response.

6. HTTP Response: The server sends back the response with a status code, headers, and body.

7. Rendering: The browser parses the response. If it is HTML, it may trigger additional requests for CSS, JavaScript, images, and fonts.

8. Connection Reuse: With HTTP/1.1 keep-alive or HTTP/2 multiplexing, the TCP connection stays open for subsequent requests, avoiding repeated handshakes.

[Browser] -> [DNS] -> [TCP 3-way handshake] -> [TLS handshake]
         -> [HTTP Request] -> [Server Logic] -> [HTTP Response]
         -> [Render Page] -> [Additional asset requests over same connection]

Why This Matters for System Design

Every arrow in an architecture diagram represents one or more of these steps. When an interviewer asks "what happens when the user clicks Submit?", they expect you to articulate this lifecycle. Latency at each step compounds: a slow DNS lookup plus a cold TCP connection plus server processing time can degrade the user experience significantly.

HTTP Versions: 1.1, 2, and 3

HTTP has evolved significantly to address performance bottlenecks:

HTTP/1.1 (1997)

• Keep-alive connections: Reuse TCP connections for multiple requests (unlike HTTP/1.0 which opened a new connection per request).
• Pipelining (theoretical): Send multiple requests without waiting for responses. In practice, rarely used due to head-of-line blocking.
• Head-of-line blocking: If the first response is slow, all subsequent responses are delayed.
• Workaround: Browsers open 6 parallel TCP connections per domain.

HTTP/2 (2015)

• Multiplexing: Multiple requests and responses share a single TCP connection, interleaved as frames. No head-of-line blocking at the HTTP layer.
• Header compression (HPACK): Reduces overhead from repetitive headers.
• Server push: Server can proactively send resources the client will likely need (e.g., pushing CSS before the browser requests it).
• Binary framing: More efficient parsing than HTTP/1.1's text-based protocol.
• Limitation: Still uses TCP, so head-of-line blocking can occur at the TCP layer if a packet is lost.

HTTP/3 (2022)

• QUIC protocol: Replaces TCP with UDP-based QUIC, which eliminates TCP-level head-of-line blocking.
• Faster connection establishment: QUIC combines the transport and TLS handshakes into a single round trip (0-RTT for repeat connections).
• Connection migration: If a user switches from Wi-Fi to cellular, the QUIC connection survives (identified by connection ID, not IP:port).

Trade-offs & Alternative Models

The client-server model is not the only architecture. Understanding its trade-offs helps you choose the right approach.

Client-Server vs Peer-to-Peer (P2P)

Stateless vs Stateful Servers

Stateless (preferred for scalability): Each request contains all information needed to process it. The server does not remember previous requests. This makes horizontal scaling trivial - any server can handle any request.

Stateful: The server maintains session state between requests (e.g., shopping cart stored in server memory). This creates sticky sessions - a client must always talk to the same server, which complicates load balancing.

Best practice: Keep servers stateless. Store session data in an external store (Redis, database) so any server can serve any request.

When Client-Server Breaks Down

• Real-time bidirectional communication: HTTP request-response is inherently one-directional (client initiates). For chat, live updates, or gaming, you need WebSockets or Server-Sent Events.
• Extremely high throughput between services: HTTP overhead (headers, text parsing in 1.1) can be too much. Internal microservices may prefer gRPC (binary protocol, multiplexed, strongly typed).
• Offline-first applications: If the client must work without a server (e.g., mobile apps in areas with poor connectivity), you need local-first architectures with sync protocols.