Como a Linear construiu um gerenciador de tarefas rápido
A Linear é uma ferramenta de tarefas e planejamento para times de software, famosa por parecer instantânea. Por baixo, é TypeScript de ponta a ponta, com um motor de sincronização próprio que guarda os dados no navegador e um único banco Postgres no Google Cloud.
Copiar stacklinear.app Gestão de projetos para times de software · Estados Unidos · fundada em 2019
Roda fluxos duráveis, inclusive o sistema de tarefas de agentes de IA em produção.
Como montaram
Velocidade em primeiro lugar, por isso o motor de sincronização próprio
Desde o começo, a Linear tratou velocidade como valor central do produto: dados guardados no próprio aparelho, nada de recarregar a página e o app funcionando offline, além de sincronização em tempo real e presença dos colegas.
Para chegar lá, o time criou um framework de sincronização próprio sobre WebSockets, pensado para ser rápido e funcionar sem internet. O CTO, Tuomas Artman, já deu palestras explicando como o motor funciona e como ele precisou mudar conforme a Linear cresceu.
Na Linear, tudo é TypeScript: dos modelos do banco aos resolvers GraphQL e aos componentes da interface. O front usa React com MobX e styled-components; o back roda em Node com Postgres, Redis e Temporal.
A mesma camada GraphQL alimenta a API pública e o SDK, então o cliente integra com a mesma API que o time usa por dentro.
Em 2024 a Linear abriu uma região na Europa. A infraestrutura era configurada à mão no us-east1 do Google Cloud, então o primeiro passo foi passar tudo para Terraform, o que facilitou muito subir uma segunda região.
Em vez de fatiar o Postgres, eles replicaram a instalação inteira por região, e o código continua falando com um único banco. Um serviço pequeno de autenticação, um Cloudflare Worker que manda cada pedido para a região certa e o Pub/Sub do Google Cloud para tarefas em segundo plano fecham o desenho.
Em janeiro de 2024, uma migração de banco apagou dados e a Linear teve que voltar o banco para um backup de algumas horas antes. O relatório do incidente cita um cache na frente do Postgres e cursores de sincronização guardados no Redis, que deixaram a recuperação mais difícil.
Depois disso, o time passou a ter avisos no CI para migrações perigosas, acesso mais restrito aos bancos de produção e testes a seco em staging.
