Realtidssamarbete – live synk utan konfliktskatten
Användare förväntar sig att se varandras ändringar direkt – ingen uppdatering, inga konflikter, inget förlorat arbete. Det är ingen funktion du lägger till i ett REST-API. Det är en annan dataarkitektur, en annan konsistensmodell och en annan uppsättning felscenarier som de flesta synkbibliotek sopar under mattan.
- 1Lokal ändringAnvändare A skriver – tillämpas optimistiskt på det lokala tillståndet
- 2OperationsloggÄndringen sparas som en CRDT-delta, inte en fullständig ögonblicksbild
- 3UtsändningDeltat skickas till alla anslutna peers via WebSocket
- 4SammanslagningVarje peer slår ihop deterministiskt – ingen konfliktdialog
- 5KonvergensAlla klienter når samma tillstånd, till slut konsistent
Offline-ändringar köas lokalt och slås ihop vid återanslutning enligt samma deterministiska regler.
Det här får du
När det passar
- Flera användare arbetar i samma dokument, canvas eller datastruktur samtidigt
- Användarna förväntar sig att ändringar dyker upp utan att sidan laddas om – ”senaste sparning vinner” är ett användarupplevelseproblem, inte en rimlig avvägning
- Du behöver offlinestöd – användare arbetar på flyg och i källare, och deras arbete ska inte försvinna
- Den nuvarande lösningen pollar var N:e sekund och kallar det ”realtid”
När det inte passar
- Samarbetet är sekventiellt, inte samtidigt – de flesta flöden där bara en användare redigerar åt gången behöver inte CRDT, de behöver ett optimistiskt gränssnitt
- Datamodellen är append-only (aktivitetsflöden, loggar, chatt) – enklare event sourcing-mönster räcker oftast
- Ditt team har aldrig levererat en realtidsprodukt tidigare – överväg ett färdigt lager (Liveblocks, Ably) först, och ta in oss när du når dess gränser
Process
Vecka 1: analys av datamodellen och en katalog över konfliktscenarier – vi kartlägger varje kombination av samtidiga ändringar innan vi skriver kod. Vecka 2–5: implementation av synkmotorn med en testrigg som spelar upp inspelade konfliktscenarier. Vecka 6–9: närvarolager, offlinestöd och skaltester. Vecka 10: dashboards för observerbarhet och runbooks.
Hela leveransprocessenPrissättning
Fast pris efter datamodellens komplexitet. Enkel text/rik text: $80–160k. Strukturerad data med egna sammanslagningsregler: $150–350k. Canvas/rumsliga data (Figma-stil): $200–500k. Integration mot ett färdigt lager (Liveblocks, Loro) går snabbare och billigare – vi rekommenderar det ärligt när det passar.
Se våra samarbetsformerBranscher där vi erbjuder det här
Vanliga frågor
- CRDT eller Operational Transform – hur väljer vi?
- OT är moget för sekventiell textredigering (används av Google Docs). CRDT:er passar bättre för strukturerad data, rumslig data och system där servern inte alltid är facit. Valet beror på din datamodell – vi kartlägger avvägningarna mot ditt schema redan vecka ett.
- Hur är det med Liveblocks eller Yjs – varför bygga skräddarsytt?
- Liveblocks, Yjs och Loro löser 80% av problemet snabbt – och vi säger till om de passar ditt användningsfall, eftersom de går snabbare att lansera med. Skräddarsydd synk är rätt när din datamodell har en logik biblioteket inte kan uttrycka (till exempel en canvas med icke-kommutativa operationer), eller när prissättningen för det färdiga lagret inte fungerar i din skala.
- Hur hanterar ni användare som blir offline mitt i en redigering?
- Offline-ändringar samlas i en lokal CRDT-deltalogg, sparad i IndexedDB. Vid återanslutning skickas deltat och slås ihop på serversidan. Sammanslagningen är deterministisk – det finns ingen dialogruta som frågar ”vilken version vill du ha?”. Det enda specialfallet är avsiktliga hårda raderingar, som vi designar som gravstenar snarare än borttagningsoperationer.
Vem som bygger det
Vårt eget team, som arbetar från vårt kontor i Istočno Sarajevo, Bosnien och Hercegovina. Ingenjörerna på ditt behovssamtal är samma personer som bygger det.
Möt teamet