Network Protocols: HTTP, gRPC, WebSocket, DNS

Every design interview eventually asks which protocol sits on the wire. We pick HTTP, gRPC, WebSocket, or SSE based on who the client is, how long the connection lives, and whether the browser has to speak it natively.

We pick the wire protocol from who talks to whom and how long the connection stays open:

Wire protocol choice shapes latency, caching, and operational complexity before we pick databases. We frame the decision around three constraints:

Walk the diagram as a request lifecycle you narrate step by step. Step 1 — DNS: client resolves a geo-routed or Anycast name to the nearest edge PoP. Step 2 — Edge entry: HTTP/REST or WebSocket hits the API gateway; static assets may short-circuit at CDN. Step 3 — Internal hop: gateway translates to gRPC over HTTP/2 inside the VPC for typed, multiplexed service calls. Step 4 — Push path: if the product needs live updates, show where the persistent WebSocket or SSE channel branches off. Use the decision tree below when the interviewer asks why not polling.

Protocol Decision Tree

Systematically analyze connection dynamics to pick the correct application protocol:

After the boxes are drawn, we anchor the discussion in protocol characteristics — each row is a talking point:

• HTTP/REST: Stateless text format (JSON), native browser integration, robust CDN edge caching compatibility.
• gRPC (HTTP/2): Strongly-typed binary Protobuf contracts, full unary/bi-directional streaming support, and connection multiplexing.
• WebSocket and SSE both push from server to client — choose based on direction and browser constraints:

Every protocol trades simplicity for performance. We articulate the price before committing:

Connection-heavy designs fail in predictable ways — we name these before the interviewer probes WebSocket scale:

These production patterns show how wire protocol and routing combine in real systems:

These production patterns show how wire protocol and routing choices combine — public HTTP at the edge, gRPC inside the mesh, WebSocket for push, and DNS only where geo-steering or failover is needed:

For error envelopes, idempotency keys, webhook HMAC, and versioning policy at the API surface — not the transport layer — see API Contract & Integration Design (#32).

Match the prompt to a protocol axis before defaulting to REST or WebSockets:

Transport choice is half the story — these concepts cover the gateway, steering, and edge layers that sit around it:

• API Contract & Integration Design (#32) — error envelopes, idempotency, pagination, and webhook contracts at the API layer (complements wire-protocol choices here).
• Proxy & Reverse Proxy Patterns — TLS termination and path routing at the gateway.
• Load Balancing Algorithms — steering at L4 (TCP) vs L7 (HTTP).
• CDN & Edge Delivery — caching static assets at the network edge.

Geography and RTT

Light in fiber sets a floor on latency — NYC to London is ~80 ms before your code runs. If users are global and you need low latency, you need regional deployments or edge caching (CDN), not just a faster algorithm on one server.

HTTP/2 Multiplexing Mechanics

Under standard HTTP/1.1, browsers are limited to a maximum of 6 concurrent TCP connections per domain. To download additional assets, requests must block in a queue (Head-of-Line Blocking at the connection level). gRPC leverages **HTTP/2** to establish a single persistent TCP connection per server, breaking data down into interleaved binary frames over multiple independent logical streams. This eliminates connection reuse latency entirely.

DNS Anycast Routing Internals

For public, high-volume entryways, systems deploy **Anycast Routing**. Instead of DNS returning different IPs depending on geographic locations, a single Anycast IP address is advertised globally via BGP (Border Gateway Protocol) routers. The global network automatically routes the client's TCP packets to the geographically closest datacenter announcing that IP, reducing connection setup times (RTT) by up to 90%.

API Design for Interviews

Protocol choice at the wire layer (HTTP vs gRPC vs WebSocket) is only half the story. Interviewers also probe how you shape the API contract itself — and how a **Proxy & Reverse Proxy** gateway sits in front to terminate TLS, route versioned paths, and translate public REST into internal gRPC.

REST vs GraphQL vs RPC

• REST: Resource-oriented URLs, cache-friendly GETs, simple for public third-party APIs. Weak when clients need wildly different field subsets from the same entity (over-fetching).
• GraphQL: Single endpoint, client-specified field selection. Excellent for mobile clients with bandwidth constraints. Cost: query complexity limits, harder CDN caching, N+1 resolver risk without DataLoader batching.
• RPC (gRPC / JSON-RPC): Action-oriented method calls with strict schemas. Best for internal microservice meshes where both sides control the contract. Requires a gateway proxy (Envoy, gRPC-Web) for browser clients.

Interview signal: public edge = REST/GraphQL behind an API gateway proxy; internal service-to-service = gRPC over a private mesh.

Cursor Pagination vs Offset

Offset pagination (?offset=10000&limit=20) degrades on large tables because the database must scan and discard 10,000 rows before returning the next page. **Cursor pagination** encodes the last seen sort key into an opaque token and queries with an indexed predicate like WHERE id > :cursor LIMIT 20 — constant-time regardless of page depth. Trade-off: cursors cannot jump to an arbitrary page number (page 47 of search results).

# Offset (slow at depth)
GET /posts?offset=10000&limit=20

# Cursor (stable cost)
GET /posts?cursor=eyJpZCI6MTIzfQ&limit=20
→ SELECT * FROM posts WHERE id > 123 ORDER BY id LIMIT 20

Idempotency Keys

Network retries make duplicate POST requests inevitable. Clients send a unique Idempotency-Key header; the API gateway or service stores the key-to-response mapping in Redis for 24 hours. A retry with the same key returns the cached response instead of creating a second payment or order. Critical for payment and booking APIs where exactly-once semantics matter at the business layer.

API Versioning: URL vs Header

• URL path (/v2/users): Explicit, easy to route at the reverse proxy layer, visible in access logs. Most common in public REST APIs.
• Header (Accept: application/vnd.myapp.v2+json): Keeps URLs stable; useful when the resource path stays the same but the response shape evolves. Harder to debug from logs alone.

Either approach works — state your choice and note that the reverse proxy can route /v1/* to legacy pods and /v2/* to new deployments, letting you run both versions side-by-side during migration (see **Proxy & Reverse Proxy Patterns**).

For structured error envelopes, webhook delivery, batch APIs with partial success, and long-running job contracts, see API Contract & Integration Design — this section focuses on wire protocol and pagination mechanics at the transport layer.