YouTube Live Stream Chat UI

Diagram#

BUFFER AND FLUSH — the core trick

  WebSocket (2.4)
    ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼   ~300 messages/sec
  ┌──────────────────────────┐
  │  in-memory buffer array  │  push only — no React state
  └────────────┬─────────────┘
               │ requestAnimationFrame / 100ms tick
               ▼
  ┌──────────────────────────┐
  │  ONE setState per flush  │  ~10 renders/sec instead of 300
  └────────────┬─────────────┘
               ▼
         bounded window

  300 renders/sec = dropped frames. 10 renders/sec = smooth.

BOUNDED WINDOW — memory must not grow with stream length

  ┌─────────────────────────────┐
  │  msg 4,981                  │  keep the last N (200–500)
  │  msg 4,982                  │  drop from the head on append
  │  …                          │
  │  msg 5,000  ← newest        │  a 6-hour stream must not
  └─────────────────────────────┘  hold 2M messages

PIN TO BOTTOM — only when the user is already there

  atBottom = scrollHeight - scrollTop - clientHeight < 40px

  atBottom  → auto-scroll on each flush
  scrolled  → STOP auto-scrolling, show "↓ Jump to latest (128)"
    up
              user is reading history; moving them is hostile

  Also: pause auto-scroll on hover, so a mouse-over freezes the feed.

How it works#

1. Never setState per message. Push into a plain array and flush on a timer or animation frame.
2. Cap the rendered window to a few hundred messages, dropping the oldest on append.
3. Virtualize if rows vary in height or the window is large (10.7).
4. Track atBottom and only auto-scroll when true; otherwise show a jump-to-latest button with an unread count.
5. Handle the extras that make it real: dedupe by message id, moderation deletions, rate-limit spam per user, and a "chat paused" state under extreme load — which is exactly what YouTube does.

const buffer = useRef([]);
useEffect(() => {
  socket.onmessage = (e) => buffer.current.push(JSON.parse(e.data));
  const id = setInterval(() => {
    if (!buffer.current.length) return;
    setMessages((prev) => [...prev, ...buffer.current].slice(-MAX));  // cap
    buffer.current = [];
  }, 100);
  return () => clearInterval(id);
}, []);

Trade-offs#

Accessibility (8.3): a live region announcing every message is unusable. Announce nothing by default, offer a "pause and read" mode, and keep the scroll container keyboard-focusable so it can be scrolled without a mouse.

Interview angle#

"Design live chat for a stream with 500k viewers."

• Client side: buffer and flush on a frame, cap the window, virtualize, and pin to bottom only when the user is already there.
• Transport: SSE or WebSocket per viewer, fanned out from a pub/sub layer — and at extreme volume the server samples messages rather than sending all of them.
• Say the quiet part: nobody can read 300 messages a second, so sampling and "chat paused" are features, not degradations.

Recap#

• Buffer in a ref, flush on a tick — one render per frame, not per message.
• Bound the window; memory must not scale with stream duration.
• Auto-scroll is conditional on the user already being at the bottom.