Real-time collaboration is not one feature.

Cursors are the first signal that you're not alone. They also reveal the first mismatch between what feels real and what's actually happening on the wire.

The cursor position you see is not the remote user's actual position. It's a stale sample, arriving at whatever rate the sender chose to broadcast — typically 10–30 times per second. Sending every pointer-move event would flood the network; not interpolating would produce visible jitter. So every collaborative tool interpolates.

Below, three ghost peers move on scripted paths. The update rate slider controls how often they broadcast their position. Toggle interpolation off and watch the cursors jump between samples instead of flowing between them.

On a 200ms connection, a pessimistic editor feels broken. Every drag, every keystroke, every color change waits for server acknowledgement before updating the UI. Users report that the product is "slow" even when the network is fine.

Optimistic updates invert the order: apply locally first, sync in the background. If the server rejects the change (e.g. a conflict or permissions error), roll back. In practice, rollbacks are rare enough that the optimistic path covers almost all sessions.

Drag the cards below. Toggle between optimistic and pessimistic, and use the latency slider to feel what a cross-continent round-trip does to a pessimistic editor.

Concurrent edits are not a bug — they're the normal condition of a shared canvas. The question isn't whether to handle them, but how.

The simplest strategy is last-write-wins (LWW): whichever edit arrives at the server most recently overwrites the previous value. It's easy to implement and works well for properties where any valid value is acceptable — like a cursor position. But for properties that represent meaningful user intent — the color of an object, the content of a text field — LWW silently discards one person's work.

The demo below simulates two peers editing the same object's color simultaneously. Both see their change applied locally (optimistic update). When both reach the server, LWW picks the later arrival. The earlier one is gone.

A CRDT is a data structure with one key property: any two replicas can be merged in any order and always arrive at the same result. The merge function is the thing you'd normally write a server for — except it runs locally, in every client, without coordination.

For object properties — color, size, label — the simplest CRDT is the LWW (Last-Write-Wins) register. Each write is tagged with a timestamp and a peer ID. On merge, the higher timestamp wins. This is essentially the same as "whoever edited last wins" — but now both clients compute the same winner locally, without asking the server.

The demo below lets you and a simulated peer ("Mia") each choose a color independently. Your timestamp is always 100ms ahead of hers — so yours wins on merge. Change the order mentally: if Mia had edited later, her color would survive.

Awareness is the layer between presence (knowing someone is here) and coordination (knowing what they're doing). In Figma, when a teammate selects a component, you see their colored selection ring and name label. You can still edit the same element — they don't hold a lock — but you have enough context to coordinate.

Hard locks — "this layer is checked out by Mia, you cannot edit it" — solve the conflict problem but create a worse one: blocked workflows, forgotten checkouts, and contention. Most mature collaborative tools abandoned hard locks in favour of soft awareness signals.

The canvas below shows two ghost peers with live selection states. Toggle soft-lock mode to see the difference between awareness-only and a visual that communicates intent more strongly.

Offline support is not a separate feature — it's a consequence of already doing optimistic updates and using a merge-safe data structure. If your local state is the source of truth for the UI and your sync protocol supports out-of-order delivery, offline just means the queue drains to zero instead of immediately.

Figma's "you are offline" banner is the most honest handling: local changes apply visually, the queue is preserved, and on reconnect the merge happens silently. The user loses nothing unless there was a hard conflict they needed to resolve.

Toggle offline, make a few edits, then reconnect. The queued edits flush into the synced state using the same LWW merge from Module 04.