Design a collaborative whiteboard (Miro)

A board is a set of independent objects with properties, so most concurrent edits do not conflict at all: Alice moves one sticky note while Bob recolours another. The simplest correct model treats each (object_id, property) as a last-writer-wins register ordered by the server: every committed change gets a monotonically increasing seq from the board's session server, and the highest seq wins. Figma has described using exactly this kind of server-authoritative, property-level LWW, inspired by CRDTs but simpler because a central server exists. Because the conflict unit is a property, Alice changing colour and Bob moving the same note both survive. Clients apply their own changes optimistically and keep a list of unacknowledged changes; when a remote change arrives for a property they have a pending change on, they ignore the remote value, because their own change will be sequenced later and win anyway. Creation uses client-generated IDs (client_id + counter) so there are no ID collisions offline. Deletion is a 'deleted' property, so a concurrent move of a deleted object does not resurrect it. Long text inside objects is the one place where a text CRDT or OT is worth it.

Z-order is tricky: if order is stored as an array of IDs, two users who 'bring to front' at the same time produce conflicting array edits. Use fractional indexing instead: each object stores a sortable string key, and moving an object between two others gives it a key strictly between their keys (for example between 'a' and 'b' you pick 'aV'). It is just another LWW property, so concurrent reorders never corrupt the list; ties are broken by object_id. Grouping and frames use a parent_id property, which can create cycles if Alice puts A inside B while Bob puts B inside A; the server validates and rejects changes that would make a cycle, and the client reverts. Connectors (arrows between shapes) store references to source and target object IDs plus an anchor side, not coordinates, so moving a shape automatically re-routes its arrows on every client. If a target is deleted, the connector keeps its last position or is deleted with it, by product rule. These details are where a whiteboard design shows depth, because they are the real bugs teams hit.

On a canvas, most of the network traffic is data nobody needs to store: cursor positions, the live position of a note while it is being dragged, selection boxes, laser pointers. Treat it as a separate, lossy channel. Clients throttle to ~10 updates per second and send only on change. The session server never writes it to the change log; it keeps only the latest value per user and drops older ones if the outgoing queue for a slow client fills (backpressure by dropping, not buffering). Broadcasts are batched per board every 50-100 ms so one WebSocket frame carries many cursors. For big workshops, cull by viewport: a user zoomed into the top-left corner does not need cursors from the bottom-right. Clients smooth motion with interpolation, so 10 updates/s look like 60 fps. Committed changes, in contrast, go through the ordered, durable path with acks. Mixing the two paths, by persisting cursor moves or by sending committed changes on the lossy channel, is a design error that interviewers notice.

A board with 100k objects and hundreds of images cannot be sent and drawn all at once on a laptop browser. On the server, the session server keeps the full object map in memory (tens of MB is fine) plus an R-tree spatial index. On open, the client can request objects intersecting its viewport first and stream the rest in the background, or download a compressed snapshot if it is small enough. On the client, rendering uses WebGL or a canvas with level-of-detail: when zoomed out, sticky notes are drawn as coloured rectangles without text, images use small thumbnails, and objects smaller than a pixel are skipped. Only objects in the viewport are drawn each frame, found via the client's own spatial index. Snapshots are rebuilt by workers every few thousand changes so that a new session server or a new client needs to replay only a short tail of the change log. Exports to PDF or PNG run as async jobs in headless renderers, because rendering 100k objects at high resolution can take minutes.

With a central session server per board, server-sequenced property-level LWW is simple, compact and easy to reason about. A full CRDT library (Yjs, Automerge) gives true offline and peer-to-peer merging but with more metadata and complexity. For an online collaboration product, server-ordered LWW is enough; use a CRDT only for rich text inside objects.

Stateless servers that write every change to a database and fan out through Redis pub/sub are simpler to operate but add latency and make ordering harder. A stateful owner per board keeps state in memory, orders changes cheaply and fans out directly; the cost is routing, rebalancing and recovery logic.

Committing every frame of a drag floods the log and history. Ephemeral previews during the drag plus one committed change on drop keep history clean and storage small.

Global undo would undo other people's work. Per-user undo stores the inverse of your own changes (previous property values) and applies them as new changes, skipping properties someone else has since changed.

Fan-out is n×n for cursors. Batch per tick, cull by viewport, cap visible cursors, and move view-only participants to read replicas that receive the committed stream from the owner.

Serialising 100k objects often is expensive. Snapshot incrementally (by frame or region chunks) and only rewrite chunks that changed.

Hundreds of full-size images freeze browsers. Generate thumbnails at upload, serve via CDN, and load full resolution only when zoomed in.

The router assigns the board to another server, which loads the latest snapshot plus the change log tail. Clients reconnect, request changes after their last seen seq, and resend unacked changes identified by (client_id, client_seq) so nothing is applied twice.

Changes queue locally; on reconnect they are sent and sequenced. Because conflicts are per property with LWW, merges are predictable; the client shows which of its changes were overridden if needed.

Version history and the change log allow restoring the board to a point in time, applied as new changes so everyone sees the restore.