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 Flow

System design diagram illustrating client DNS lookup, TCP/TLS handshake, web proxy termination, and backend service dispatch.

100%
Loading system design canvas…

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 Flow

Visual flow depicting client query dispatched to Recursive Resolver, Root Server, TLD Server, and Authoritative DNS.

100%
Loading system design canvas…

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).

FeatureTCP (Transmission Control Protocol)UDP (User Datagram Protocol)
Connection StateConnection-oriented (requires 3-way handshake)Connectionless (sends packets immediately)
ReliabilityGuaranteed delivery with packet retransmissionNo delivery guarantee (packets may drop)
OrderingStrict sequence preservation via sequence numbersNo ordering guarantees (packets can arrive out of order)
Header Overhead20 to 60 bytes header size8 bytes lightweight header size
Flow & Congestion ControlYes (sliding window algorithms, slow start)No (sender controls speed independently)
Typical Use CasesHTTP/HTTPS, Database connections, SSH, gRPCVideo 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 Flow

Diagram depicting state transitions and packet sequence exchanges between Client and Server sockets.

100%
Loading system design canvas…

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 Flow

Architecture flow illustrating key share negotiation, certificate verification, and symmetric secret derivation.

100%
Loading system design canvas…

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 Flow

Diagram comparing HTTP/1.1 connection queueing, HTTP/2 binary multiplexing, and HTTP/3 QUIC over UDP.

100%
Loading system design canvas…

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.

ParadigmData TransportPrimary StrengthsIdeal Use Case
RESTHTTP/1.1 or HTTP/2 + JSON/XMLStandardized CRUD semantics, strong browser support, straightforward HTTP cachingPublic web APIs, standard web applications
gRPCHTTP/2 + Protocol Buffers (Binary)Ultra-low latency, strongly typed contracts (.proto), tiny binary payloads, streaming supportInternal microservice-to-microservice communication
GraphQLHTTP + JSON (Single POST endpoint)Client specifies exact fields needed; eliminates over-fetching and under-fetchingComplex mobile applications with diverse UI data views
WebSocketsTCP Socket (HTTP Upgrade)Full-duplex, real-time bi-directional streaming over a persistent connectionLive 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 Flow

System design diagram comparing REST, gRPC binary streams, GraphQL queries, and WebSockets full-duplex channels.

100%
Loading system design canvas…

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?