Scaling the Linear Sync Engine

…you've modeled and implemented the data-layer (which does require you to rethink / unlearn a few principles), you don't need to worry about data-fetching, errors etc. as much as in a regular "API-based" app. Another interesting video I recommend on this topic is about Linear's "Sync Engine" which employs some of the local-first techniques as well: link to this video…

You may not need CRDT per-se, but building a collaborative experience is so difficult. I worked on collaborative systems for a bit, and also have read a bit about how Figma and Notion do it (this is a good read: link ) -- it's still super hard to get right. This talk by Karri about Linear's "sync engine" is also a good watch: link to this video .

How Linear scaled their sync engine

Heads-up: This is a video ( link to this video ) embedded in a blog post; there doesn't seem to be an accompanying text-only version.

(this should probably be a post) CRDTs and local first are ideas that is perpetually in the hype cycle for the last decade or so, starting around the time Riak CRDTs became a thing and continuing all the way to today. Niki's post is a perfect illustration: CRDTs offer this "magical" experience that seems perfectly good until you try building a product with them. Then it becomes a nightmare of tradeoffs: - state-based or operation-based? do you trim state? how? - is it truly a CRDT (no conflicts possible), a structure with explicit conflict detection, or last-writer-wins/arbitrary choice in a trench coat that will always lose data? Case in point: Automerge uses pseudo-random conflict resoluti…

> Previous sync engines really want you to sync all data Linear had to do all sorts of shenanigans to be able to sync all data, for orgs with lots of it – there's a talk on that here: link to this video