Every design has to answer two protocol questions: how bytes travel between machines (layer 4: TCP or UDP), and what the messages mean (layer 7: REST, gRPC, WebSockets and so on). This lesson is the quick decision guide. The detailed lessons on transport and application protocols go deeper.
What each layer can see#
A component working at layer 4 sees only the "envelope": source and destination IP addresses and ports. A component at layer 7 opens the "letter" and reads the HTTP method, path, headers and cookies. Reading more costs more CPU, but lets you make smarter decisions.
Start with sensible defaults#
Most designs never need to leave the defaults.
- Default to REST over HTTP, on TCP. Only switch when the problem gives you a reason: very tight latency, real-time updates, or awkward data-fetching patterns. Starting simple shows you are pragmatic and not over-engineering.
- A common hybrid: REST for public, external traffic (easy for anyone to use) and gRPC for internal service-to-service traffic (faster and strictly typed).
Layer 3 and 4 choices#
At the lower layers you decide who can reach each machine and how reliably bytes travel.
- IP addressing: give the load balancer a public IP so the world can reach it. Keep app servers and databases on private IPs so they can't be reached directly from the internet.
- TCP (reliable): use it whenever data must arrive correctly and in order: payments, bids, logins, ordinary web traffic.
- UDP (fast): use it when losing the odd packet is fine and latency matters most: live video, games, voice calls.
- Browsers can't use raw UDP. For browser users you need WebRTC (which uses UDP underneath) or a TCP-based fallback such as WebSockets, often with batching. Details are in Transport Layer Protocols.
Layer 7 API styles#
For request-response calls, pick one of three API styles.
| Style | Strengths | Watch out for | Typical use |
|---|---|---|---|
| REST | Simple, cacheable, works everywhere | Over- and under-fetching; JSON parsing cost | Public APIs, most web apps |
| gRPC | Binary Protobuf is compact and fast to parse; HTTP/2 multiplexing; strict schemas | Poor native browser support; harder to debug by eye | Internal microservice calls, e.g. checkout → fraud check |
| GraphQL | Client asks for exactly the fields it needs in one round trip | Harder to cache; easy to write queries that hammer the database (N+1) | Complex frontends with changing data needs |
REST conventions worth remembering:
- Noun-based URLs:
GET /v1/users/1, notGET /getUser. - Statelessness: every request carries what the server needs (for example, a JWT or API key), so any server can handle it.
- Idempotency:
GET,PUTandDELETEshould give the same result if called twice.
Real-time push#
When the server needs to push updates, there are two main options.
| Server-Sent Events (SSE) | WebSockets | |
|---|---|---|
| Direction | One way: server → client | Two way |
| Built on | Plain HTTP | HTTP upgrade, then a raw TCP channel |
| Strengths | Simple; browsers reconnect automatically | Either side can send at any time |
| Pain points | Proxies and load balancers may close idle connections, so send a heartbeat every 15–30 seconds | Stateful: each server must track every open connection, which is harder to scale |
| Use for | Notifications, stock prices, live scores | Chat, multiplayer games, collaborative editing |
Don't reach for WebSockets unless the client really needs to send frequent messages back.
Common gotchas#
A few details trip people up in interviews.
- 301 vs 302 redirects. A 301 (permanent) is cached by the browser, so later clicks never reach your server. That is fast, but you lose analytics. A 302 (temporary) sends every click through you, so you can count them.
- HTTPS protects the pipe, not the content. An attacker can still send whatever request body they like. Never trust a user ID in the body. Take identity from the validated session or token.
- Web server vs API server. A web server (for example nginx) serves HTML, CSS and JavaScript. An API server (for example a Python FastAPI app) handles data and logic. Keep them separate so you can scale each on its own.
Quick reference#
Common scenarios and the protocol that fits each.
| Scenario | Best choice | Why |
|---|---|---|
| Placing a bid | TCP + REST | Every bid must arrive, in order |
| Streaming a movie | HTTP adaptive streaming (HLS/DASH) | Works on every device and through standard CDNs |
| Chat with typing indicators | WebSockets | Frequent two-way messages |
| Stock price updates | SSE | One-way push, browser friendly, reconnects on its own |
| Internal microservice calls | gRPC | High throughput, low latency, compact binary |
Worked scenarios#
Driver location on a rider's map. The app sends a driver's GPS position to a rider every 2 seconds.
- Choice: SSE over HTTP (so TCP).
- Why: the rider only watches; they don't send data back every 2 seconds. SSE also reconnects automatically when the phone's signal drops.
Syncing an order book between internal services. A matching engine streams thousands of buy and sell orders to an analytics engine in the same data centre.
- Choice: gRPC (HTTP/2 over TCP), with updates batched.
- Why: both sides are internal, so Protobuf keeps serialization cheap and throughput high. Batching avoids flooding the network with tiny messages.
"Typing..." indicator in a chat app. The indicator must appear and clear almost instantly as the other person types.
- Choice: WebSockets over TCP.
- Why: constant, low-latency messages flowing both ways.
Live reactions during a global event. Ten million people tap "like" at the same moment.
- Choice: SSE or WebSockets to deliver updates, over TCP.
- Why: instead of forwarding ten million tiny events, the server batches them ("1,000 likes in the last 100 ms") and pushes one update. That keeps servers and clients from being overwhelmed.
How streaming works in browsers#
Most video uses HTTP over TCP. Real-time interactive media uses UDP. WebSockets carry app data, not raw video.
- HTTP adaptive streaming (TCP): Netflix, YouTube, Twitch VODs. The video is cut into chunks of a few seconds that the browser downloads one after another. TCP retransmits lost packets, so quality is perfect, at the cost of a buffer of several seconds.
- WebRTC (UDP): video calls (Google Meet, Discord), interactive live streams. Frames go peer-to-peer or through media servers. A lost packet is skipped rather than waited for, which keeps latency low.
- WebSockets (TCP): chat, notifications, game state. Because TCP waits for lost packets to be resent, WebSockets would stutter for video. They are often used alongside WebRTC for signalling, the setup messages that start a call.
Key takeaways#
- L4 components see only addresses and ports. L7 components read the request and can route on it, at extra CPU cost.
- Default to REST over TCP. Add gRPC internally, GraphQL for complex frontends, and SSE or WebSockets for real-time features only when needed.
- TCP for anything that must be correct. UDP for real-time media where a dropped packet is better than a late one.
- Pick SSE for one-way push and WebSockets for frequent two-way messages.
- Batch high-volume updates to protect servers and clients.