Linear — the local-first sync engine.
Most issue trackers are server-rendered apps with cached client state. Linear is the inverse: a local-first sync engine that happens to look like an issue tracker. That single architectural choice is the entire product moat.
The architecture — from public signals
The five things you can see from outside.
Client is the source-of-truth
Disable your network. Keep working. Every operation succeeds locally. On reconnect, operations replay. Not optimistic UI — a genuinely local-first model with full IndexedDB persistence. Zero perceived latency per keystroke.
WebSocket transport, custom merge brain
Long-lived WSS per session. Operations flow up; remote operations flow down. The merge logic isn't a generic CRDT — it's domain-specific (knows about issues, sub-issues, status, ordering).
Workspace logical sharding
Every customer = workspace. Per-workspace logical shard in Postgres, with the path to physical sharding when scale demands. The shared-MT with cell-readiness pattern.
Search is a separate concern
Search index lives close to the user (per-workspace shard) and is populated by the sync engine on the write path. Reads never hammer FTS against the primary store.
Two protocols, two audiences
GraphQL for external integrations (selective field queries from partners). Bespoke compact sync protocol over WebSocket for the internal client. Dramatically more efficient for high-frequency bidirectional updates.
What to steal. What to avoid copying.
Steal — the patterns that compound
- Local-first is feasible in 2026 in a way it wasn't in 2019. IndexedDB is mature; WASM sync engines are mature. Pick local-first for write-heavy single-user-edits-many-things; skip for read-mostly shared dashboards.
- Two protocols for two audiences — GraphQL for partners; bespoke for your own client. Don't make them share a wire format.
- Workspace-as-tenant + logical sharding readiness from day one. Tenant ID in every row; shard-key chosen so physical sharding is non-breaking later.
- Search via write-path, not query-time FTS — dramatically faster.
Avoid copying — unless you're them
- Custom sync engine if a generic CRDT fits — Linear built custom because their semantics demanded it. If you're text-collaboration or simple state-sync, use Yjs/Automerge.
- Full local-first for read-mostly products — analytics, observability, CMS. Local-first shines for write-heavy edits; overkill elsewhere.
- WebSocket as the only transport — expensive at scale (sticky sessions, reconnect logic). Linear pays this cost; if 1-second latency is OK, polling/SSE is simpler.
What this teardown can't tell you
- Conflict-resolution rules at the operation level (concurrent status changes, sub-issue parenting races).
- Physical sharding strategy today — logical pattern is public; physical reality isn't.
- GDPR right-to-erasure implementation across sync log + index + Postgres.
- Cost-per-workspace at scale — the always-on WebSocket has real economics.
Linear is what an issue tracker looks like when you optimise for perceived latency above every other engineering concern — and the engineering organisation is willing to pay the architectural cost competitors using server-rendered architectures cannot match without a rewrite.
Methodology & sources
Public signals only. Company engineering blog posts, conference talks, job ads, public GitHub, podcasts, product behaviour from the outside. No NDA-covered information; no private conversations. The architecture inferred is my analysis — not endorsed by or affiliated with Linear.
Primary sources:
- Linear engineering blog · linear.app/blog — especially “Scaling the Linear Sync Engine”
- Talks by Tuomas Artman (co-founder/CTO) on architecture decisions
- Public GraphQL API · developers.linear.app
- Open-source @linear/sdk client
- Linear public job listings (sync engine · Rust/Go infra)
- Direct observation of offline behaviour, WebSocket traffic, IndexedDB persistence.
Found this useful? More coming.
One teardown per quarter. Tell me which architecture you'd want analysed next.