FSD Frontend System Design

Part I — The Pipes · Lesson 2.7

Picking a Transport

In one lineAnswer three questions in order — direction, frequency, tolerance for staleness — then defend the cost.

Where you've seen itA live order screen runs four transports at once, each chosen for a different piece of the UI.

  • Time14 min
  • DiagramDecision tree + cost table + one screen using four transports
  • Chapter2 · Communication

Diagram

diagram
DECISION TREE

              Does the client need to SEND, not just receive?
                              │
              ┌───────────────┴───────────────┐
             YES                              NO
              │                                │
         WebSocket                    How often does it change?
       (chat, cursors,                         │
        games, collab)          ┌──────────────┼──────────────┐
                            > 1 min       1s – 1 min       < 1s
                                │              │              │
                          Short polling   Long polling       SSE
                          (+ ETag, jitter) (or SSE)      (ticker, feed,
                                                          token stream)

        Event starts in ANOTHER system, no browser?  ──►  WebHook
diagram
COST TABLE — what you pay per 10,000 concurrent clients

                    requests/min   open conns   server state   you write
  ──────────────────────────────────────────────────────────────────────
  Short poll (5s)     120,000           0           none        nothing
  Long poll (30s)      20,000       10,000          list      cursor logic
  SSE                       0       10,000        last-id      almost none
  WebSocket                 0       10,000       session      reconnect,
                                                              resubscribe,
                                                              replay
  WebHook                   0            0         queue      idempotency
diagram
ONE SCREEN, FOUR TRANSPORTS — the answer interviewers want

  ┌──────────────────────── Order tracking ────────────────────────┐
  │                                                                │
  │  Order details, address    ← REST, fetched once                │
  │  Status: "Preparing"       ← SSE, changes ~5 times per order   │
  │  Rider on map              ← SSE, 1 update/sec while moving    │
  │  Chat with rider           ← WebSocket, both sides send        │
  │  "Delivered" notification  ← Web Push, works with tab closed   │
  └────────────────────────────────────────────────────────────────┘

How it works

  1. Direction first. Client must send → WebSocket. Otherwise you're choosing among pull options and SSE.
  2. Frequency second. Minutes → poll. Seconds → long poll or SSE. Sub-second → SSE or WebSocket.
  3. Staleness third. If a 30-second-old value is harmless, polling is the cheaper, simpler answer — and it survives every proxy.
  4. Then name the cost you accepted: wasted requests, held connections, or reconnect code you now own.
  5. Then name the fallback and the offline behaviour. Every streaming answer needs one.

Trade-offs

Don't use WebSocket ifDon't use SSE ifDon't use polling if
Only the server has newsThe client must sendSub-second freshness matters
You can't run a pub/sub backplaneYou're stuck on HTTP/1.1 with many streamsClients number in the millions
The feature is a notification badgeYou need binary payloadsBattery and data cost matter

Interview angle

"Design real-time updates for a stock trading dashboard."

  • Prices: SSE — one-way, high frequency, and free reconnect with replay by Last-Event-ID.
  • Order placement and fills: WebSocket, because the client sends and needs sub-second acknowledgement.
  • Throttle on the client: coalesce ticks into one render per animation frame, or the UI dies before the network does.

Recap

  • Direction → frequency → staleness. Three questions, in that order.
  • State the cost you accepted and the fallback you'd ship; that's the senior signal.
  • Mixing transports on one screen is the correct answer, not a compromise.