Real-time co-editing for rich text documents, structured forms, and mixed-content pages built on mathematically sound conflict resolution rather than last-write-wins. For rich text, we use Yjs (CRDT-based, excellent for peer-to-peer and offline scenarios) or ShareDB (OT-based, mature and production-proven for server-coordinated editing similar to Google Docs). ProseMirror as the rich text editor framework: its immutable document model and transformation API integrate cleanly with both Yjs and ShareDB, and its plugin architecture handles custom node types (tables, embeds, code blocks) without fighting the collaboration layer. Character-level merging for text: two users typing in the same paragraph at the same time produces the correct merged result without either user's changes being silently discarded. Field-level conflict handling for structured data: a shared form where User A updates the price field and User B updates the description field simultaneously applies both changes correctly without needing character-level OT. Operational log stored in append-only format in PostgreSQL -- every change is a record, making version history and point-in-time restore a query rather than a snapshot restore.

Multi-user canvas applications where users add, move, resize, and style objects simultaneously -- built with the specific architectural patterns that prevent z-order conflicts, selection races, and inconsistent coordinate state across users. Fabric.js or Konva.js as the canvas renderer: both support the per-object event schema (object ID, operation type, delta coordinates) required for the synchronisation layer to apply remote operations optimistically on the local canvas without a server round-trip. Optimistic local rendering: a user's own drag operation updates their canvas immediately, with the operation broadcast to other users and the server state updated asynchronously -- so the interaction feels instant even at 100ms WebSocket latency. Z-order CRDT for layer management: a CRDT-based sequence type handles concurrent "bring to front" and "send to back" operations on overlapping objects without either user's operation being silently discarded. Object-level soft locking: when a user selects an object, other users see it highlighted with the selecting user's colour -- a non-blocking indicator that discourages simultaneous manipulation without preventing it. Per-user cooperative undo/redo: undoing restores your last operation without reverting other users' concurrent changes.

Shared spreadsheet-style interfaces and multi-user form workflows where different users fill in different sections concurrently -- including cases where the sections overlap and the application needs to decide how to handle that gracefully. Field-level soft lock with acquisition and release: when a user focuses a field, the server broadcasts a "field focused" event to all room members showing a coloured indicator and the editing user's avatar; the lock is released when the user leaves the field or after a configurable inactivity timeout (typically 15 seconds) so an idle user's focus doesn't permanently block a field. Last-write-wins with attribution for fields where any conflict is unlikely and automatic merge is cleaner than forcing users to coordinate: the winner's value is applied and the change history shows which user made the last update and when. Yjs Map CRDT for structured data where concurrent updates to different keys must both persist: two users updating different metadata fields of the same record see both changes applied without either being discarded. Row-level locking for spreadsheet interfaces: a user editing a row sees other users' cursor positions within adjacent rows, with the currently-edited row soft-locked to prevent confusing simultaneous edits.

User awareness features that make collaboration feel spatial rather than asynchronous -- the features users describe as "it feels like we're working in the same room." Yjs Awareness protocol for presence state: each user's cursor position, selection range, display name, and avatar colour broadcast to all room members via the same WebSocket connection as document operations, with automatic cleanup when a user disconnects. Named cursor overlays rendered at the correct document position with smooth animation as the user types or selects -- the cursor doesn't jump, it moves. Avatar stack in the document header showing all currently active users with a configurable overflow ("+3 others") when the room is large. Active-section highlighting: the paragraph or section another user is currently editing receives a coloured background highlight in their colour, so users can see at a glance where activity is happening without watching cursor coordinates. Typing indicator in chat panels: broadcast while active, cleared after 2 seconds without input. Idle state after 30 seconds of inactivity: the user's cursor becomes translucent and their avatar shows a clock indicator -- they're still connected but not actively editing, reducing false impression of concurrent activity.

The mathematical conflict resolution layer that determines what the document contains when two users edit the same location simultaneously -- and the guarantees that come with each approach. Operational Transformation (OT): each operation is transformed against concurrent operations before application, maintaining the property that applying A then B produces the same result as applying B then A regardless of message order. OT requires a central server authority to establish operation order -- appropriate for server-coordinated tools like a shared CRM record editor. ShareDB implements OT for JSON and rich text with a production-proven track record. CRDTs (Conflict-free Replicated Data Types): data structures mathematically designed so that any merge order produces identical results, enabling offline editing and peer-to-peer sync without a central authority. Yjs implements CRDT types for Text (character-level), Array (list with insert/delete), and Map (key-value with concurrent update) -- composable to model complex document structures. The trade-off: OT requires a central server but has smaller memory overhead per character; CRDTs support offline and P2P but carry metadata overhead that grows with operation history. We choose based on your specific offline requirements and deployment topology, and document the guarantees so your team understands the edge cases.

Operation-log-based version history with per-user attribution -- built from the same operation log that drives synchronisation rather than as a separate snapshot mechanism. Every character insertion, deletion, formatting change, and structural operation is recorded with the user ID, timestamp, and operation data. The history UI reconstructs any prior state by replaying or reversing the operation log to any point in time, without storing a full copy of the document at every change. Named snapshots for milestone versions (the "Draft for review" snapshot vs. automatic continuous history) stored as a named pointer into the operation log rather than a document copy. Per-user cooperative undo: undoing your last action reverses your operation without reverting other users' concurrent changes that were applied after yours -- distinguishing it from a simple stack-based undo that would also undo their work. Point-in-time restore for entire documents: select any timestamp in the history, preview the document state at that point, and optionally restore it as the current version (which creates a new operation, not a history rewrite). The operation log is stored in PostgreSQL in append-only format, making it queryable for change attribution, audit requirements, and product analytics on editing patterns.