Collaborative Whiteboard with Conflict-Free Sync

The problem real-time collaboration hides

Real-time collaboration looks simple and is not. Two people move the same sticky note at the same moment; one deletes a shape the other is recolouring; a teacher's laptop drops off the campus Wi-Fi for ten minutes and comes back with changes. Every device must end in the same state, without a server deciding every keystroke and without anyone silently losing work. Teams, classrooms and remote study groups use whiteboards exactly this way, often on unreliable connections.

What already exists and the gap

• Excalidraw is an open source whiteboard with live collaboration; its maintainers have discussed moving to CRDT based sync in public issues.
• tldraw is an open source whiteboard SDK with its own sync library and an example built on Yjs.
• Figma described its multiplayer system as inspired by CRDTs but with a central server as the authority.
• Yjs and Automerge are mature CRDT libraries used under many collaborative editors.

These are excellent, and that is the point: importing Yjs reduces this to a drawing app with a websocket, which is not a final year project. The gap for you is understanding. Implementing the merge semantics yourself, testing them adversarially, and comparing your design with a production library is the contribution, and it is exactly the knowledge real-time product teams look for.

What you build

Users are small teams and classes who share a board link. Main flows: open a board, draw together with live cursors, go offline and keep drawing, reconnect and merge, share a read only link.

Architecture: each client holds a full replica and applies local operations immediately. Operations carry unique ids and logical timestamps. The server relays and stores operations but never resolves conflicts.

The technically interesting part

Ordering and identity. Decide what happens when one user deletes an object while another moves it, when two users set the same colour concurrently, or when both reorder layers. Use a last writer wins register per property with Lamport timestamps and replica ids as a tie break, an add and remove set for objects, and a fractional index or sequence CRDT for z-order. Write down each rule and why.

Proving convergence. A randomised property test: generate long sequences of concurrent operations across simulated replicas, deliver them in random orders with duplicates and partitions, and assert every replica reaches an identical state. When it passes reliably over thousands of runs, you have a real result. Show your supervisor a failing seed you found and fixed.

Growth. Tombstones and operation logs grow forever unless you compact. Measure it.

How to evaluate it

• Convergence: number of randomised runs and operations tested, and every bug found by the test.
• Latency: local operation to remote render time for 2, 5 and 10 clients; target under 100 ms on a local network.
• Offline: partition two clients for ten minutes of edits each, reconnect, and verify convergence and no lost work.
• Comparison: document size and merge time for your CRDT against Yjs or Automerge on the same recorded session.
• User test: five pairs complete a joint diagram task; record conflicts they noticed.

Suggested plan

1. Weeks 1 to 2: read CRDT fundamentals; design operations on paper.
2. Weeks 3 to 5: CRDT core in pure TypeScript with the property test from day one.
3. Weeks 6 to 8: relay server, presence, minimal canvas editor.
4. Weeks 9 to 10: offline storage, reconnection, compaction.
5. Weeks 11 to 14: benchmarks, library comparison, user test, write up.

Path to a product

Treat it first as an open source library and portfolio centrepiece: a small, well tested CRDT for canvas documents with a clear write-up is the kind of work that gets interviews at product companies building real-time features. A product path exists too, a whiteboard for tutoring or classrooms that works well on poor connections, sold per teacher, but only after the sync core is solid.

Scope warning

Keep drawing tools minimal. Rectangles, freehand, text and selection is enough. Every hour on drawing features is an hour not spent on sync, which is what is being assessed. Do not add video calls, chat, accounts beyond a board link, or end to end encryption in the core scope.

Learn what you need on Sefism

• System design roadmap : consistency, replication and real-time architecture.
• System design cheat sheet : quick reference for the trade-offs you will discuss.
• All Things Distributed : eventual consistency explained by people who run it at scale.
• How to learn system design as a student : where this project fits in your learning.
• MDN: HTTP : the protocol under the WebSocket upgrade and your relay server.

Get help with this idea

The sync design and the convergence test are what examiners will judge. Tauseef can help you pick CRDT designs your team can finish, set up the property test early, and plan benchmarks that stand up in a viva. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session