A discussão entre monorepo e multirepo costuma ser enquadrada como preferência arquitetural, mas, na minha avaliação, o efeito prático da escolha só aparece quando se observa o tempo entre uma mudança que atravessa múltiplos componentes e a sua disponibilidade em produção. Em times distribuídos, esse intervalo é dominado por dois tipos de custo: o custo de coordenar mudanças que tocam mais de um serviço, e o custo de manter tooling consistente entre repositórios que evoluem em ritmos diferentes. A topologia do repositório determina qual desses custos é absorvido pela plataforma e qual é transferido pro engenheiro que está tentando entregar a mudança, e é essa transferência que define a velocidade agregada de entrega.
Em organização com muitos repositórios pequenos, o padrão que vejo se repete. Uma mudança que altera contrato entre dois serviços exige coordenar ao menos dois pull requests, em dois repositórios, com dois pipelines de CI independentes, possivelmente com code owners diferentes e certamente com ciclos de revisão desacoplados. O engenheiro abre o primeiro PR e aguarda aprovação. Depois do merge e do deploy, só então abre o segundo PR contra a nova versão. O tempo total de ciclo se multiplica não pelo número de repositórios envolvidos, mas pelo produto das latências humanas de cada um, porque cada transição entre repositórios introduz uma janela de espera que não existe dentro do mesmo repositório. A pesquisa do Google sobre o próprio monorepo descreve esse efeito como redução de atrito em mudanças atômicas, e é um dos principais motivos pelos quais a empresa manteve bilhões de linhas em um único repositório apesar do custo de infraestrutura (Google Research).
O monorepo absorve esse custo ao permitir que mudanças atravessem múltiplos componentes em um único commit, com uma única revisão e um único pipeline de validação. A mudança de contrato e a adaptação dos consumidores viajam juntas, e o CI valida o conjunto antes do merge, eliminando o estado intermediário inconsistente que existe naturalmente no multirepo durante a janela entre os dois deploys. O CI faz o trabalho de coordenação que o engenheiro faria à mão entre dois PRs, e a redução de lead time em mudanças cross-cutting cai diretamente desse mecanismo. O custo, em contrapartida, aparece em ferramentas. Build systems que funcionam bem em repositórios pequenos começam a apresentar tempos de execução inaceitáveis à medida que o monorepo cresce, e build incremental, cache distribuído e invalidação precisa de dependências passam a ser pré-condição de operação, e não refinamento opcional. Bazel e Buck2 atendem workloads poliglotas em escala, enquanto Nx e Turborepo cobrem o ecossistema JavaScript, e todos existem precisamente porque o monorepo só escala quando o tooling trata o grafo de dependências como dado primário (Turborepo).
O trade-off inverso aparece em ownership. Em multirepo, cada repositório é uma fronteira de autonomia natural: o time dono define sua política de branch, seu pipeline, seu ritmo de release, sua stack interna. Em monorepo, essas decisões são compartilhadas por construção, e a tentativa de preservar autonomia exige mecanismos explícitos, como CODEOWNERS, políticas de lint por diretório, pipelines seletivos baseados em caminho de mudança e convenções de diretório que substituem a fronteira física do repositório. Times distribuídos que operam em fusos diferentes sentem esse custo de forma desigual: o engenheiro que precisa de uma aprovação de código em outro continente pra mergear uma mudança num diretório que ele raramente toca paga em horas de espera algo que no multirepo seria resolvido por deploy independente. A autonomia de release, que no multirepo é default, no monorepo precisa ser construída, e a construção exige disciplina que, na minha experiência, nem toda organização possui.
A granularidade certa depende de propriedades concretas da organização, e a escolha real opera em granularidade antes de operar em polo. Times cujos componentes são fortemente acoplados em domínio e fracamente acoplados em release ganham mais com monorepo, porque a coordenação de mudança é o custo dominante. Times cujos componentes são fracamente acoplados em domínio e precisam de autonomia de release em escalas de tempo diferentes ganham mais com multirepo, porque a fronteira natural do repositório se alinha com a fronteira do ciclo de entrega. A maioria das organizações grandes opera algum híbrido, com monorepos por domínio ou por plataforma, e o desenho desses agrupamentos tem mais impacto na velocidade de entrega do que a escolha abstrata entre os dois modelos. Organizações com dezenas de microsserviços distribuídos em dezenas de repositórios tipicamente observam lead times de mudanças cross-cutting medidos em dias, dos quais a fração de trabalho efetivo é pequena, e a consolidação em poucos monorepos por domínio, combinada com build tool de cache remoto, costuma reduzir esse lead time em uma ordem de grandeza sem sacrificar a autonomia de release entre os agrupamentos. O que muda na prática é o desenho das fronteiras, de forma que cada repositório contenha o conjunto de componentes que efetivamente mudam juntos. Pra mim, a pergunta útil gira em torno de qual agrupamento minimiza coordenação humana sem comprometer autonomia de release, e essa pergunta tem resposta diferente em cada organização.