O que eu errei sobre monorepos

Passei dois anos defendendo que separássemos nosso monorepo. Os tempos de build estavam subindo, a fila do CI travava toda sexta-feira, e qualquer proposta de adicionar um novo serviço acabava emperrada em discussões sobre onde o código deveria morar. Eu tinha gráficos. Eu tinha um plano. Olhando para trás, eu estava discutindo a coisa errada.

A fronteira que eu de fato protegia não era técnica — era social. Dois times tinham se distanciado na forma como revisavam código, na velocidade que queriam imprimir, e no quanto de risco estavam dispostos a carregar numa sexta à tarde. Separar o repositório deixaria cada time definir seu próprio ritmo, mas eu vendia a ideia como uma correção de performance de build, e performance de build acabou sendo a parte mais fácil de resolver.

Resolvemos o problema real de build com cache melhor e um grafo de tarefas que só reconstruía o que de fato mudou — algumas semanas de trabalho de infraestrutura, não uma migração. A fronteira social levou mais tempo: CODEOWNERS separados, ciclos de release separados, uma biblioteca compartilhada com uma política real de depreciação em vez de “só não quebra”. Nada disso exigia um segundo repositório.

Se eu fosse defender o caso de novo, começaria pelo organograma, não pela estrutura de pastas. A questão da ferramenta quase sempre tem resposta; a questão de quem é dono do quê, e o quanto de atrito cada lado está disposto a aceitar do outro, é que de fato decide se separar ajuda.