Echtzeit-Kollaboration – Live-Sync ohne Konfliktkosten
Nutzer erwarten, die Änderungen der anderen sofort zu sehen – ohne Neuladen, ohne Konflikte, ohne verlorene Arbeit. Das ist kein Feature, das man einer REST-API einfach hinzufügt. Es braucht eine andere Datenarchitektur, ein anderes Konsistenzmodell und andere Fehlerszenarien, über die die meisten Sync-Bibliotheken hinweggehen.
- 1Lokale ÄnderungNutzer A tippt – wird optimistisch auf den lokalen Zustand angewendet
- 2OperationsprotokollÄnderung wird als CRDT-Delta erfasst, nicht als vollständiger Snapshot
- 3BroadcastDelta wird per WebSocket an alle verbundenen Peers gesendet
- 4MergeJeder Peer führt deterministisch zusammen – kein Konfliktdialog
- 5KonvergenzAlle Clients erreichen denselben Zustand, eventual consistent
Offline-Änderungen werden lokal gesammelt und bei der Wiederverbindung nach denselben deterministischen Regeln zusammengeführt.
Was Sie bekommen
Wann es passt
- Mehrere Nutzer arbeiten gleichzeitig am selben Dokument, Canvas oder derselben Datenstruktur
- Nutzer erwarten, dass Änderungen ohne Neuladen der Seite erscheinen – das Prinzip „der letzte Speichervorgang gewinnt“ ist ein Usability-Problem, kein akzeptabler Kompromiss
- Sie brauchen Offline-Unterstützung – Nutzer arbeiten im Flugzeug oder im Keller, und ihre Arbeit darf nicht verschwinden
- Die aktuelle Lösung fragt alle paar Sekunden per Polling ab und nennt das „Echtzeit“
Wann nicht
- Zusammenarbeit läuft nacheinander, nicht gleichzeitig – die meisten Workflows, bei denen jeweils nur ein Nutzer bearbeitet, brauchen keine CRDTs, sondern ein optimistisches UI
- Das Datenmodell ist nur anfügend (Activity-Feeds, Logs, Chat) – einfachere Event-Sourcing-Muster reichen meist aus
- Ihr Team hat noch nie ein Echtzeitprodukt ausgeliefert – prüfen Sie zuerst eine Managed-Lösung (Liveblocks, Ably) und holen Sie uns dazu, sobald Sie an deren Grenzen stoßen
Ablauf
Woche 1: Analyse des Datenmodells und Katalog der Konfliktszenarien – wir erfassen jede mögliche Kombination gleichzeitiger Änderungen, bevor der erste Code entsteht. Wochen 2–5: Umsetzung der Sync-Engine mit einer Testsuite, die aufgezeichnete Konfliktszenarien nachspielt. Wochen 6–9: Presence-Schicht, Offline-Unterstützung und Skalierungstests. Woche 10: Observability-Dashboards und Runbooks.
Der vollständige AblaufPreise
Festpreis nach Komplexität des Datenmodells. Einfacher Text/Rich-Text: $80–160k. Strukturierte Daten mit individuellen Merge-Regeln: $150–350k. Canvas/räumliche Daten (Figma-Stil): $200–500k. Die Integration einer Managed-Lösung (Liveblocks, Loro) ist schneller und günstiger – wir empfehlen sie ehrlich, wenn sie passt.
Zusammenarbeitsmodelle ansehenBranchen, in denen wir das umsetzen
FAQ
- CRDT oder Operational Transform – wie wählen wir?
- OT ist ausgereift für sequenzielle Textbearbeitung (so arbeitet Google Docs). CRDTs eignen sich besser für strukturierte Daten, räumliche Daten und Systeme, in denen der Server nicht immer die Autorität hat. Die Wahl hängt von Ihrem Datenmodell ab – wir stellen die Abwägungen für Ihr konkretes Schema in Woche eins gegenüber.
- Was ist mit Liveblocks oder Yjs – warum eine eigene Lösung bauen?
- Liveblocks, Yjs und Loro lösen 80% des Problems schnell – und wir sagen Ihnen, wenn sie zu Ihrem Anwendungsfall passen, weil sie sich schneller ausliefern lassen. Eine individuelle Lösung lohnt sich, wenn Ihr Datenmodell Semantik braucht, die die Bibliothek nicht abbilden kann (etwa ein Canvas mit nicht-kommutativen Operationen), oder wenn sich die Preise der Managed-Lösung bei Ihrer Größenordnung nicht rechnen.
- Wie gehen Sie damit um, wenn Nutzer mitten in der Bearbeitung offline gehen?
- Offline-Änderungen sammeln sich in einem lokalen CRDT-Delta-Log, das in IndexedDB gespeichert wird. Bei der Wiederverbindung wird das Delta gesendet und serverseitig zusammengeführt. Der Merge ist deterministisch – es gibt keinen Dialog „welche Version möchten Sie behalten?“. Der einzige Sonderfall sind bewusste endgültige Löschungen, die wir als Tombstones und nicht als Entfernen-Operationen konzipieren.
Wer es baut
Unser eigenes Team arbeitet aus unserem Büro in Istočno Sarajevo, Bosnien und Herzegowina. Die Engineers in Ihrem Erstgespräch sind dieselben, die es später auch bauen.
Das Team kennenlernen