Part I — The Pipes · Lesson 2.1
Communication Overview
In one lineTwo questions decide everything: who starts the message, and how often does it arrive?
Where you've seen itA single Swiggy order-tracking screen runs three transports at once — REST for the order, a stream for rider location, push for the doorbell moment.
Diagram
THE ONLY TWO AXES THAT MATTER
ONE-WAY (server → client) TWO-WAY (both talk)
┌───────────────────────────┬──────────────────────┐
RARE │ Short polling │ REST request │
(minutes) │ "any news?" every 60s │ user-initiated │
├───────────────────────────┼──────────────────────┤
OCCASIONAL │ Long polling │ Long poll + POST │
(seconds) │ held request │ │
├───────────────────────────┼──────────────────────┤
FREQUENT │ Server-Sent Events │ WebSockets │
(sub-second) │ score ticker, feed │ chat, cursors, games│
└───────────────────────────┴──────────────────────┘
Server → Server, event-driven: WebHooks (no browser involved)PULL vs PUSH — who pays the cost?
PULL client asks repeatedly cost = wasted requests
● ─?─► ○ ● ─?─► ○ ● ─✓─► ○
2 empty answers before 1 useful one
PUSH server sends when it knows cost = held connections
● ◄──────── ✓ ── ○
zero waste, but the server tracks every clientHow it works
- Decide direction. Only the server has news → SSE or polling. Both sides talk → WebSocket.
- Decide frequency. Slower than a minute → poll. Faster than a second → stream.
- Decide the cost you can pay. Polling burns requests; streaming burns open connections and server memory.
- Always design the fallback. Corporate proxies still block WebSockets; mobile networks drop streams on backgrounding.
Trade-offs
| Transport | Direction | Cost per client | Reconnect logic |
|---|---|---|---|
| Short polling | pull | N requests/min | none needed |
| Long polling | pull, feels like push | 1 held request | you write it |
| WebSocket | duplex | 1 socket + state | you write it |
| SSE | server → client | 1 held response | built in |
| WebHook | server → server | none (no client) | retry queue |
Interview angle
"Design the update mechanism for a food-delivery tracking screen."
- Split by frequency: order status changes rarely (poll), rider location changes constantly (stream).
- Use SSE for location because it's one-way and reconnects itself; save WebSockets for the chat with the rider.
- State the fallback and the reconnect/backoff policy — that's the part candidates skip.
Recap
- Direction and frequency pick the transport; everything else is detail.
- Pull wastes requests, push holds connections — choose which cost you prefer.
- Real screens mix transports; one answer for the whole app is a red flag.