Design a Live Whiteboard Session

Problem statement

Design a live whiteboard service where multiple participants draw, sketch, drop shapes, add sticky notes and text on a shared infinite canvas, and every participant sees each other's strokes within a few tens of milliseconds. The product must synchronize freehand pen strokes, geometric shapes, text boxes, colors, erasing, layering (z-order), selection, and presence (live cursors), while supporting save-for-later, board history, and optional chat or voice integration.

This is not a classic rich-text document problem. Operational Transformation was built for one-dimensional sequences where insert and delete operations must be re-based against concurrent edits. A whiteboard is closer to a shared map of independent graphical objects: two users editing different strokes do not conflict at all, two users moving the same shape conflict on position, and two users redrawing the same region conflict on overlap semantics. The concurrency model therefore favors per-element, per-property convergence (last-writer-wins registers with a server-assigned ordering, or a CRDT map) rather than global string re-basing.

Why the problem is distinctive

A chat system can deliver messages in order and be done. A whiteboard must reconcile concurrent mutations of shared mutable state so that all replicas converge to the same canvas without a visible 'fight' between users. At the same time, the input rate is high: a pen moving at 60-120 Hz produces a continuous stream of points, and broadcasting every raw point to every viewer is a fanout and bandwidth problem. The design must separate three loops that run at different speeds and with different consistency needs:

1. The render loop (local, 60 fps, optimistic, never blocks).
2. The sync loop (network, batched strokes and property ops, convergence within ~100 ms).
3. The presence loop (ephemeral cursors and selections, lossy by design).

A strong interview answer states early that local echo is instant and authoritative for the drawing user, while remote updates are interpolated and reconciled, and that losing presence updates is acceptable but losing or duplicating committed strokes is not.

The four planes

1. Session plane: room lifecycle, membership, roles, permissions, and join/leave.
2. Sync plane: operation ordering, conflict resolution, snapshots, and offline reconciliation.
3. Presence plane: live cursors, selections, typing indicators, and awareness.
4. Asset plane: images, saved boards, history, and export.

Keeping these planes separate lets presence degrade or drop without affecting committed canvas state, and lets the sync plane stay correct even when a presence channel is congested.

Public operating baseline versus design assumptions

Public evidence shows the category is real and large. Figma has publicly described its multiplayer engine, where a central server orders operations and clients apply them, and has reported millions of daily users editing design files collaboratively. Miro has publicly reported tens of millions of registered users collaborating on visual boards. Excalidraw, an open-source whiteboard, publishes its collaboration approach (WebSocket broadcast with end-to-end encrypted rooms). Microsoft built the Fluid Framework specifically for real-time collaborative applications, and Canva ships a collaborative whiteboard. These are cited company figures and product descriptions for context, not requirements for our fictional system.

For capacity planning this answer assumes a mature product with 2 million daily active editors, 300,000 concurrently connected participants at global peak, 90,000 simultaneously active board sessions, and a 5x event peak for launches, classes, and retrospectives. Unless a number is tied to a citation, it is a stated design assumption, target, or budget, not a claim about any company's private architecture.