Technically Speaking: How $400 million Runs on a 25 Person Team
Part 2 of a series on excellent applications and what it takes to make them
Let me first start off by saying, Linear has done something incredible and worthy of emulating. The reason I’m diving into the nuts and bolts of their sync engine is because I am inspired by work like theirs.
As I dove into the engine, it became clear to me that part of the reason they have done so well, is because they are skilled engineers AND they nailed choosing their tradeoffs.
This is also something difficult to replicate. There are some clues into how they made it work though.
Sync When It’s Easy
When I was first introduced to local first applications, everything I read about talked extensively about data structures called CRDTs. CRDTs are a data structure that mathematically guarantee ways to resolve conflicts between multiple clients working on the same object.
The big tradeoffs with CRDTs are space and complexity. Besides the inherent complexity of the structure, over time they can become massive which can lead to lots of problems with the experience and performance of an application.
Aside: Ink and Switch are a thought leader in research on this and have an article about how they are leveraging CRDTs for one of their applications. TLDR is, it is very cool engineering and complicated. You should check it out. They have a live example of the capability in the article.
One of the first things I noticed when diving into Linear’s sync engine, is that their sync “logic” largely does not rely on this methodology.
It’s kinda basic and I love it.
They use what’s known as a “last update wins” method of resolution which is exactly what it sounds like. Whatever value comes in last for the field, is the value of the field.
This is from Figma’s “How Figma’s multiplayer technology works.” It has some great examples of different sync methods
They understood early on, that most editing would be done on single property fields. Think a title or an assignee for a task. Because of this, “last update wins” is good enough and can power most of their sync.
The Server is Unreliable, Use the Client Instead
Another insight from the direction of Linear’s tech stack was that a primary cause of poor experience was related to waiting around for network calls. A side effect of relying on a server for everything, is it creates a nice bottleneck. Hardware is expensive at scale. Software that is optimized requires expensive engineers.
One piece of this that shocked me maybe shouldn’t have. Most of the data that your Linear app has, is stored on the client. Almost all of it. Every team, user, ticket, comment, etc…
When you install Linear for the first time, it performs a “bootstrapping” operation that syncs most of the relevant data.
The great part about this is, after this initial load, the client can now be used for the majority of everything that the user needs. This can significantly reduce the load on the server and the related costs that come from needing to scale that infrastructure.
So how does Linear keep that data in sync? They open a live connection from the app to their sync engine. The sync engine will then broadcast out all new changes that each client needs to register.
If the user goes offline for some time, they can ask for all updates since a certain transaction, and replay those transactions on their local database so they are up to date. Tuomas provides a more detailed explanation for this in his breakdown of Linear’s sync technology here.
Sync Engine Equals Scale?
Throughout this research on Linear, one thing kept coming up. The sync engine was making it possible for Linear to ship more frequently and with a smaller team.
So the sync engine is the reason for this incredible capability to scale. How could you or I replicate this?
As I mentioned in the previous article, “Why Linear is Winning the Experience Game” this is Tuomas’s 4th sync engine. Part of the trick is looking at solutions like this and getting an understanding of how they work. The other part is going out there and building the real deal.
One thing that’s harder to copy: they had a lot of time to just build the sync engine before anything else. That is unique and not usually a luxury afforded to a startup.
Considering all of this, you should pursue learning tech like this, but manage your expectations. Your first attempts at this will probably hurt. The outcomes Linear is getting are real and tangible though and worth the effort.
They are running a $400 million dollar business with a team of 25.
I think trying to replicate that is worth a little pain.
Thanks for reading!
If you enjoyed this post, and you’re interested in more content about how excellent applications are created, pledge your support to show that this content is interesting and worth continuing! You won't be charged I enable payments.
Below are a series of excellent articles, videos and podcasts I used to research this content:
Initial design and architecture of the Sync Engine (2020)
Improving the Sync Engine for Performance (2023)
Podcast reviewing Linear’s sync Engine with Tuomas (2024)
Open Sourced version of Sync Engine at Uber
Gergely Orosz Excellent Interview with Tuomas Artman (2022)
Peritext: a CRDT for rich text editing
How Figma’s multiplayer technology works
About Me
I’m Paul Hovley. I’ve been a software developer for the past 10 years and was CTO of a dev shop that was acquired. I’ve always told people that I want to be more giving with my time so I’m trying to live by my words better and doing something I believe in. I’m working 20 hours a week to pay the bills while I try my hand at building something for people. The app I’m working on is ebb.cool. Check it out!
Ebb is a desktop app to help minimize distractions during important times of the day when you are trying to create. If you’re interested in helping we have a 100 or so creators in our Discord that are passionate about being better. If you’re also passionate about self improvement and focus, we’d love to have you. Look forward to hearing your story!
