Two people type into the same sentence at the same moment. On both screens, a moment later, the sentence looks the same, and both people's words are in it. That's the entire trick, and it's much harder than it looks.
In this lab you'll design a collaborative editor like Google Docs. Most of it is ordinary: documents, permissions, storage. The hard part is a single question: when edits cross in flight, how does every copy end up the same without losing anyone's work? You'll meet the two big answers, operational transformation and CRDTs, and pick one.
The brief
People write documents together: a team drafting a plan, students on a group project, a hundred people filling in a shared sign-up sheet. Everyone sees everyone else's typing within a fraction of a second, along with coloured cursors showing who is where.
For this lab:
- In: real-time co-editing of rich text, cursors and presence, short offline periods (a train tunnel), version history.
- Out: comments and suggestions, spreadsheets and slides, export to PDF, the sharing and permissions model beyond "can edit" or "can view".
Requirements
Functional
- Several people can edit the same document at the same time.
- Each person sees others' edits and cursors live.
- An editor who goes offline briefly can keep typing, and their edits merge when they reconnect.
- Users can view and restore earlier versions.
Non-functional
- Every copy of a document converges to the same content. No two people should ever end up looking at different text.
- No acknowledged edit is ever lost, even if a server crashes.
- Others see an edit within 200 ms when everyone is in the same region.
- Typing is never blocked by the network. Your own keystrokes appear instantly.
- Up to 100 simultaneous editors per document. Many more can view.
Notice the tension between the last three. Your keystrokes must appear immediately, which means your copy changes before the server has seen the edit. So for a moment every copy is different. The design has to bring them back together.