Multi-User Collaboration Interfaces

⚡ Miro-like Platform — System Design (Foundations) Miro is a cloud-based, real-time collaborative whiteboard used by teams to brainstorm, map user journeys, run workshops, and co-design products on an infinite canvas. It combines shapes, sticky notes, text, images, connectors, and templates with multi-user presence (live cursors, comments) and rich integrations (e.g., Jira, Slack, Figma) so distributed teams can ideate and align visually synchronously or asynchronously without losing context or momentum. Task How I’d architect a real-time, infinite-canvas whiteboard that scales from 10 → 10,000 concurrent editors with sub-100–150 ms perceived latency globally. Why it's important - Teams expect instant feedback, global access, and zero lost work. The hard parts: realtime sync, conflict resolution, per-board sharding, durable storage, and deep observability. Assumptions - Web and desktop clients; mobile is read/edit with constrained tools. Boards are multi-tenant; data locality by region. Editors ≤ 200 per board (hard), viewers can spike to thousands (fan-out optimized). MVP Scope 1) Infinite canvas: shapes, text, connectors, pen 2) Multi-user presence & live cursors 3) Undo/redo + autosave 4) Sharing & roles (viewer/editor) Targets (v1 SLOs) - Latency: P95 end-to-end update ≤ 150 ms - Budget: 20 ms client processing · 40 ms network to edge · 40 ms server/ordering 30 ms fan-out · 20 ms render - Capacity: ≤ 200 active editors/board; ≥ 5k passive viewers (efficient broadcast) - Reliability: RPO ≤ 5 s, RTO ≤ 10 s (snapshotting + warm standby) Load/Join: cold-start join for 10k-element board ≤ 1.5 s (snapshot + delta) The core loop (realtime path) 1) Clients send ops over WebSocket. 2) Sync node orders & merges (OT to start; CRDT for offline-first later) then broadcasts. 3) Batch/interval persistence to NoSQL; periodic snapshots to Blob. 4) Presence/cursors via throttled, coalesced events. Key early decisions 1) Transport: WebSockets first; fallback only if required. 2) Consistency: Start OT (central arbiter, lean metadata); evaluate CRDT when offline/P2P becomes a must. 3) Sharding: All traffic per board → one sync node (sticky by BoardID) for ordering and simplicity. 4) Durability: Event deltas + periodic snapshots; warm standby for fast failover. Guardrails (anti-herd & backpressure) - Client-side: cursor throttling (e.g., 15Hz), draw coalescing, exponential backoff + jitter on reconnect. - Server-side: token-bucket per client/board, admission control for hot boards, fan-out batching (≤ 8 ms), drop/slow path for purely ephemeral presence. - Data: TTL for presence keys in Redis; compaction of stale ops; snapshot GC. #SystemDesign #DistributedSystems #WebSockets #CRDT #OT #Scalability #Miro #Architecture #NoSQL #Redis #Kafka #ClickHouse #Observability

I recently spent time understanding how Google Docs handles multiple people editing the same document in real time. What looks like a simple product feature is actually a very interesting distributed systems problem. I came across three approaches used in collaborative editing systems: 𝗢𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝗧𝗿𝗮𝗻𝘀𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 (𝗢𝗧) This is the approach historically associated with Google Docs. If two users edit the same part of a document at the same time, the system transforms operations so everyone eventually sees the same result. What makes this difficult is preserving user intent while operations arrive out of order. 𝗖𝗥𝗗𝗧𝘀 (𝗖𝗼𝗻𝗳𝗹𝗶𝗰𝘁-𝗳𝗿𝗲𝗲 𝗥𝗲𝗽𝗹𝗶𝗰𝗮𝘁𝗲𝗱 𝗗𝗮𝘁𝗮 𝗧𝘆𝗽𝗲𝘀) This approach takes a different path. Instead of resolving conflicts afterward, the data structure itself is designed so concurrent edits merge consistently across all clients. Different users can make changes independently, and the system still converges to the same document state. 𝗗𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁𝗶𝗮𝗹 𝗦𝘆𝗻𝗰𝗵𝗿𝗼𝗻𝗶𝘇𝗮𝘁𝗶𝗼𝗻 This one was particularly interesting to read about. Instead of syncing operations, the system continuously compares document differences and exchanges patches between clients. The biggest realization for me was this: Collaborative editing is fundamentally a distributed systems problem disguised as a text editor. Behind every shared document, the system is dealing with: - concurrent edits - network latency - out-of-order events - reconnects - consistency guarantees And yet the experience feels seamless to the user. The more I learn about systems like this, the more I appreciate how much engineering exists behind products we use every day.

Multi-agent systems should be designed to include human as well as AI agents. A new open-sourced interface from Microsoft does exactly that. In Magentic-UI, a lead Orchestrator coordinates specialist agents - including humans - using 6 simple collaboration models as a starting point. In testing, Magentic-UI completed about 82% of everyday web tasks and 46% of tougher challenges entirely on its own. When it paused to ask a human for a quick pointer, only 10 % of tasks, accuracy went up by 71 %. This shows that when human guidance is asked for just when needed, it can lead to substantial performance improvement with minimized effort. The six models used by Magentic-UI are instructive. Remember this is a user interface, a way of improving how humans are involved in AI task performance. These models are inspiration for a host of other possible interaction forms. 🧭 Co-planning Before the agent takes any action you see its step-by-step plan laid out like a checklist and can reorder, delete or rewrite items until the flow matches your intent. Nothing executes until you click Accept, so you keep full control from the very first move. 🔄 Co-tasking During execution either party can hit Pause to take the wheel, type a clarifying prompt, or manually click through a tricky web page. This back-and-forth makes the agent feel more like a cooperative colleague than a black-box bot. 🛑 Action approvals When an irreversible or high-risk step—like sending money or deleting data—comes up, an ActionGuard popup asks for a quick Yes/No. The task cannot proceed without your explicit green light, adding a safety net against costly mistakes. 🔍 Answer verification Once the agent claims it’s done you can replay its entire click-by-click history or drill down with follow-up questions to double-check the output. This audit trail builds trust and helps catch edge-case errors before they matter. 💾 Memory Any successful workflow can be saved as a named template, so next time a similar request arrives the agent starts with a proven plan instead of reinventing the wheel. Over time this growing library turns ad-hoc successes into reusable best practices. 🌐 Multi-tasking You can run several autonomous sessions side by side—each in its own tab—with status icons that flag which ones are waiting for your input. This lets you supervise multiple jobs at once without losing track of progress. We need more of this thinking. Humans + AI agent workflows are the future.