Design a collaborative whiteboard

An edit says 'set these properties on this shape'. Each stored value carries a stamp: a logical clock number and the ID of the client that wrote it.

The logical clock is a counter on each client. When a client makes an edit it uses its counter plus one. When it receives any operation, it sets its counter to the larger of its own and the one it saw. So an edit made after seeing another always has a higher clock. Two edits made without seeing each other may tie, and the client ID breaks the tie. Stamps compare as a pair: clock first, then client ID.

The rule is last writer wins, for each property separately. An incoming value replaces the stored one only if its stamp is higher. The same set of operations gives the same board in any order, and a repeated operation changes nothing, so replays, retries and offline merges are safe. If Alice resizes a note while Bob recolors it, both edits survive, because they touch different properties. If both drag it, one position wins on every screen, and the loser sees the note jump. That loss is acceptable on a whiteboard.

Stacking order. If the order were an array index, two people sending shapes to the front at once would clash. Give each shape an order key instead, a value that sorts between its neighbours. Between 0.40 and 0.50 a new shape can take 0.45. In practice keys are short strings that sort in order, so precision never runs out. Two people who pick the same key are ordered by shape ID. Moving a shape in the stack is one property change on one shape, so no other shape is rewritten. After many inserts at one spot keys grow long, and the server rebalances them in a quiet moment.

Deletes. Deleting sets a deleted flag with a stamp. This is a tombstone, and it is just another property, so it merges like the rest. A later edit to a deleted shape is kept but hidden, and undoing the delete is a newer write of the flag. Compaction drops a tombstone once every connected client has passed it and a retention period, such as 30 days, is over.

Text inside a note is one property here, so two people typing in the same note at once overwrite each other. For long text, use a text-merging technique like the one in the collaborative editor problem, for that property only.

Durable operations are 200,000 a second in and 600,000 out, while cursors are 2 million in and 6 million out. They need different treatment.

The durable channel. Operations go to the board server, which merges them, appends them to the log, acknowledges, and broadcasts. The app keeps each operation until it is acknowledged, and resends after a reconnect. Each carries a client ID and a sequence number, so the server drops duplicates. The acknowledgement is sent only after the append is durable.

The ephemeral channel. Cursor positions, selections and drag previews go to the cursor relay. The rules:

• Cap each person at 20 updates a second, one every 50 ms, and send only the latest position when several happen.
• Do not acknowledge, store or retry. A lost update is replaced by the next one.
• Expire each person's entry after 5 seconds with no update, so a closed tab disappears.
• Send updates only to people whose window covers that part of the board.

A drag preview shows a shape moving while it is still held. Send its in-progress position on the ephemeral channel. Send one durable operation when the person lets go, and one every second or so during a long drag, so that a crash does not lose the move.

Crowds. With n people, cursor messages grow as n × (n − 1). For 4 people that is 12 per round. For 100 it is 9,900. So lower the rate as the board fills: 20 a second at 10 people or fewer, 5 a second above 50, and only cursors in view. Past a few hundred people, show most as viewers with no live cursor.

Load shedding. If a connection's send buffer backs up, discard the older cursor updates for it. Never drop durable operations. Slow the sender down instead.

All its operations meet there, so ordering needs no consensus protocol. Our estimate gives 100 servers for 100,000 active boards.

Log plus snapshots. Every operation is appended to the log with a position number. Every few thousand operations, or after a quiet period, the server writes a snapshot of the whole board and the log position it covers. After a crash, a new owner loads the latest snapshot and replays the log from that position.

Tiles. Divide the canvas into square tiles, say 1,000 by 1,000 units, and store the snapshot per tile. A shape belongs to the tile that holds its center. Opening a board loads the tiles under the window: about 200 shapes and 40 KB, against 4 MB for the whole board. The app then subscribes to those tiles, and the server sends it only the operations for shapes in them. As the person pans, the app asks for the next tiles. An arrow between shapes in different tiles is sent together with the shapes at its ends.

A shape that is moved across a tile boundary is just a property change, and the server updates its tile index. A very large shape is listed in each tile that it touches.

Offline. While offline, the app keeps applying edits locally and queues the operations, each with its stamp. On reconnect it sends the queue and the last log position it saw. The server merges each property by stamp, so an offline edit that a newer edit has already overtaken loses that property, and the rest still land. The server replies with the operations after that position. If the app has been away longer than the retention period, tombstones may be gone, so it reloads the board and keeps its queue as a draft to apply again.