System Design: Client-Server Fundamentals
Master the underlying network protocols, request-response lifecycles, transport layers, and API communication paradigms that power modern distributed web applications.
Client-Server Architecture and the Request-Response Cycle
Client-server architecture partitions tasks between service providers called servers and service requesters called clients. In web engineering, clients are typically browsers, mobile applications, or third-party API consumers, while servers are specialized compute instances executing business logic and managing data persistence.
Every interaction begins with a request sent by the client over a network connection. The server processes this request, validates incoming parameters, queries databases or external services, and returns a response packet containing status codes, headers, and payload data. This exchange operates synchronously or asynchronously depending on the underlying transport layer.
Phases of the Request-Response Cycle
When a user types a URL or triggers an API call, several distinct network operations occur in strict sequence before bytes appear on screen:
- 1. Name Resolution:The client converts the domain name into an IP address using local cache or recursive DNS queries.
- 2. Connection Establishment:The client opens a socket connection to the target server IP and port via TCP handshake.
- 3. Security Handshake:If TLS is configured, client and server negotiate cryptographic ciphers and exchange certificate validation keys.
- 4. Payload Transmission:The HTTP request header and payload travel across network routers to the destination server.
- 5. Server Execution & Response:The server dispatches the request to an application worker, builds the output document, and returns HTTP status 200 along with response payload.
End-to-End Client-Server Pipeline Flow
Client-Server FlowSystem design diagram illustrating client DNS lookup, TCP/TLS handshake, web proxy termination, and backend service dispatch.
DNS Resolution, IP Addressing, and Network Ports
Computers on a network communicate through numerical IP addresses (IPv4 like 192.0.2.1 or IPv6 like 2001:db8::1). Because human users remember domain names rather than hex strings, the Domain Name System (DNS) operates as a globally distributed database translating human-readable hostnames into network addresses.
DNS resolution uses a hierarchical lookup chain. When a client requests a domain, the resolution flows through four server layers: local browser cache, recursive resolver (provided by an ISP or public DNS like 1.1.1.1), root name servers, TLD (Top-Level Domain) name servers, and finally authoritative name servers holding the canonical DNS records.
Essential Network Primitives
- A & AAAA Records:A maps hostnames to 32-bit IPv4 addresses; AAAA maps hostnames to 128-bit IPv6 addresses.
- CNAME Records:Canonical Name aliases one domain to another domain name, enabling flexible server routing without changing IP targets.
- IP Ports:Numerical endpoints (0 to 65535) on an IP host. Port 80 defaults to unencrypted HTTP; port 443 defaults to encrypted HTTPS; port 5432 defaults to PostgreSQL.
- Sockets:An active network connection defined by a source IP, source port, destination IP, and destination port combination.
Hierarchical DNS Resolution Architecture Flow
DNS FlowVisual flow depicting client query dispatched to Recursive Resolver, Root Server, TLD Server, and Authoritative DNS.
The OSI Model, TCP, and UDP
The Open Systems Interconnection (OSI) model standardizes network communication into seven conceptual layers: Physical (Layer 1), Data Link (Layer 2), Network (Layer 3), Transport (Layer 4), Session (Layer 5), Presentation (Layer 6), and Application (Layer 7). In modern web design, developers interact primarily with Layer 4 (Transport) and Layer 7 (Application).
| Feature | TCP (Transmission Control Protocol) | UDP (User Datagram Protocol) |
|---|---|---|
| Connection State | Connection-oriented (requires 3-way handshake) | Connectionless (sends packets immediately) |
| Reliability | Guaranteed delivery with packet retransmission | No delivery guarantee (packets may drop) |
| Ordering | Strict sequence preservation via sequence numbers | No ordering guarantees (packets can arrive out of order) |
| Header Overhead | 20 to 60 bytes header size | 8 bytes lightweight header size |
| Flow & Congestion Control | Yes (sliding window algorithms, slow start) | No (sender controls speed independently) |
| Typical Use Cases | HTTP/HTTPS, Database connections, SSH, gRPC | Video streaming, VoIP, Online multiplayer gaming, DNS queries |
TCP Three-Way Handshake
Before any application data travels over TCP, client and server exchange three control packets to synchronize sequence numbers:
- 1. SYN:Client sends a segment with SYN flag set and an initial sequence number x.
- 2. SYN-ACK:Server acknowledges with ACK number x+1, SYN flag set, and server initial sequence number y.
- 3. ACK:Client responds with ACK number y+1. The full-duplex TCP socket is now connected and ready for HTTP payload data.
TCP 3-Way Handshake Connection Flow
TCP FlowDiagram depicting state transitions and packet sequence exchanges between Client and Server sockets.
TLS/SSL Handshake and Encryption in Transit
Transport Layer Security (TLS), the successor to Secure Sockets Layer (SSL), encrypts traffic between client and server to prevent eavesdropping, tampering, and message forgery. HTTPS is simply standard HTTP traffic operating inside an encrypted TLS session.
Modern TLS 1.3 optimizes the connection setup. While TLS 1.2 required two full network round trips (2-RTT) to negotiate cryptographic keys, TLS 1.3 completes the entire handshake in a single round trip (1-RTT). It achieves this by combining key exchange algorithms (such as Diffie-Hellman) with certificate authentication in the initial ClientHello exchange.
TLS 1.3 Key Exchange Steps
- ClientHello:Client sends supported cipher suites, key share parameters, and Server Name Indication (SNI).
- ServerHello & Certificate:Server chooses the cipher suite, provides its public key share, presents its X.509 digital certificate signed by a trusted Certificate Authority (CA), and proves ownership via a digital signature.
- Symmetric Secret Derivation:Both sides independently derive matching session encryption keys. Application data payload transmission begins immediately using AES-GCM or ChaCha20-Poly1305 symmetric ciphers.
TLS 1.3 1-RTT Handshake Sequence Flow
TLS FlowArchitecture flow illustrating key share negotiation, certificate verification, and symmetric secret derivation.
HTTP Protocol Evolution: HTTP/1.1, HTTP/2, and HTTP/3
Hypertext Transfer Protocol (HTTP) has evolved significantly over three decades to meet the performance requirements of modern web scale. Understanding how each protocol version manages transport connections helps software engineers optimize front-end assets and API performance.
Comparing HTTP Generations
- HTTP/1.1 (1997):Text-based protocol. Introduced persistent TCP connections (Keep-Alive) and pipelining. Suffixes from head-of-line (HOL) blocking: if a single slow request stalls on a connection, subsequent requests behind it are delayed.
- HTTP/2 (2015):Binary framing protocol. Introduced multiplexing over a single TCP connection, HPACK header compression, and server push. Eliminates HTTP-level head-of-line blocking, though packet loss at the TCP layer can still stall all multiplexed streams.
- HTTP/3 (2020+):Replaces TCP with QUIC (a UDP-based transport protocol with integrated encryption). Eliminates TCP-level head-of-line blocking entirely: packet loss on one stream does not impact independent parallel streams on the same connection.
HTTP Protocol Framing & Transport Evolution Flow
HTTP Evolution FlowDiagram comparing HTTP/1.1 connection queueing, HTTP/2 binary multiplexing, and HTTP/3 QUIC over UDP.
API Paradigms: REST, gRPC, GraphQL, and WebSockets
Selecting the appropriate client-server communication style depends on data access patterns, latency bounds, payload serialization costs, and client types.
| Paradigm | Data Transport | Primary Strengths | Ideal Use Case |
|---|---|---|---|
| REST | HTTP/1.1 or HTTP/2 + JSON/XML | Standardized CRUD semantics, strong browser support, straightforward HTTP caching | Public web APIs, standard web applications |
| gRPC | HTTP/2 + Protocol Buffers (Binary) | Ultra-low latency, strongly typed contracts (.proto), tiny binary payloads, streaming support | Internal microservice-to-microservice communication |
| GraphQL | HTTP + JSON (Single POST endpoint) | Client specifies exact fields needed; eliminates over-fetching and under-fetching | Complex mobile applications with diverse UI data views |
| WebSockets | TCP Socket (HTTP Upgrade) | Full-duplex, real-time bi-directional streaming over a persistent connection | Live chat applications, collaborative documents, stock updates |
Trade-offs Between API Styles
No single API paradigm fits every service boundary:
- Use REST when:You need wide compatibility, public accessibility, and standard HTTP response caching via CDNs.
- Use gRPC when:You are building high-throughput microservices inside a backend cluster where minimal latency and strict type safety matter most.
- Use GraphQL when:Front-end applications need custom data shapes from multiple relational tables in a single network round trip.
- Use WebSockets when:Server-initiated pushes are frequent and establishing HTTP connections repeatedly incurs unacceptable handshake overhead.
API Paradigm Architecture Comparison Flow
API Paradigms FlowSystem design diagram comparing REST, gRPC binary streams, GraphQL queries, and WebSockets full-duplex channels.
Knowledge Check
Knowledge Check
1. What happens during a DNS lookup when visiting a web page?
2. Which network protocol layer does HTTP operate on in the OSI model?
3. What is the primary difference between TCP and UDP?
4. Why does HTTP/2 offer better performance than HTTP/1.1 over high-latency networks?
5. When should a developer choose WebSockets over traditional HTTP polling?