Monorepo vs Polyrepo Comparação: Dados de 320 Equipes
Resumo
Monorepos têm mediana de ciclo de PR de 19h versus 2h para polyrepos (Faros AI, 320 equipes). A escolha não é de preferência: é uma função da taxa de mudanças cross-service da sua organização. Abaixo de 30%, polyrepo costuma compensar. Acima de 30%, o imposto de coordenação começa a superar o custo de tooling do monorepo. Meça antes de decidir.
Esta monorepo vs polyrepo comparação não começa com uma recomendação: começa com uma medição. Qual percentual das suas features exige mudanças em mais de uma fronteira de serviço? Se você não souber esse número, está tomando uma decisão de infraestrutura baseada em preferência de equipe. E numa organização de 50 engenheiros, essa preferência vai custar o domingo de alguém.
A palavra-chave aqui é cálculo. Ambas as abordagens impõem custos. A pergunta é qual custo sua organização absorve melhor: o imposto de coordenação do polyrepo ou o investimento em tooling do monorepo.
O Tempo de Ciclo de PR Resolve a Discussão. Mas Não Completamente.
A Faros AI analisou 320 equipes de engenharia ao longo de 12 meses e constatou que ambientes monorepo têm mediana de tempo de ciclo de PR de 19 horas. Ambientes polyrepo: 2 horas.
Isso é uma diferença de 9,5x na mediana. No percentil 90, a diferença cai para 8,6 dias contra 5,5 dias -- mas ambas as caudas são lentas. A média também se aproxima: 3,6 dias no monorepo, 2,8 dias no polyrepo.
O contra-argumento é bem estabelecido: monorepos têm builds individuais mais rápidos quando o cache funciona. Uma equipe de polyrepo coordenando uma mudança cross-service em cinco repositórios, com cinco CI pipelines separados e cinco conjuntos de aprovação de CODEOWNERS, não vai fechar um PR em duas horas tampouco.
Os dados capturam tempos de ciclo para PRs típicos, não mudanças cross-cutting de pior caso. Essa distinção importa. Equipes de polyrepo citam sua mediana (rápida, porque a maioria dos PRs delas é isolada). Defensores de monorepo citam a dor de coordenar entre repositórios (também real, documentada nas caudas de pior caso). Os dois lados estão certos sobre cenários diferentes.
Os dados não encerram o debate. Eles descrevem o tradeoff com mais precisão do que intuições fazem.
O Blast Radius que Você Não Está Calculando
Aqui está o que raramente aparece nos slides de conferência: num monorepo, uma dependência compartilhada quebrada afeta todos os serviços que a importam, no mesmo commit, antes que qualquer pessoa com ownership downstream tenha revisado a mudança.
Num polyrepo, um pacote com versão quebrada afeta os serviços que fazem upgrade, mas só quando eles fazem upgrade. O blast radius é diferido e limitado pela escolha do consumidor.
Isso importa para rollouts com SLO gate. Uma biblioteca compartilhada com bug num monorepo não oferece janela de canary. Oferece um blast radius cross-service num único evento de deploy. Seu error budget começa a queimar em múltiplos SLOs simultaneamente antes que a automação de rollout detecte o padrão e acione o revert.
Num polyrepo, o rollout de uma mudança de dependência compartilhada é sequencial por natureza. O serviço A faz upgrade e você observa o SLO dele. O serviço B faz upgrade três dias depois. O blast radius em qualquer momento é limitado por quem já adotou a mudança.
A pergunta não é qual estrutura é inerentemente mais segura: é qual é o seu primitivo de deployment. Se sua unidade de deployment é o serviço com seu próprio SLO gate, o polyrepo oferece isolamento natural. Se sua unidade de deployment é a mudança atômica de feature pousando de forma consistente em frontend, API e worker em segundo plano simultaneamente, o monorepo oferece essa coordenação sem drift de versionamento.
A maioria das equipes que entregam microsserviços tem o primeiro problema. A maioria das equipes que entregam uma superfície de produto fortemente acoplada tem o segundo.
Por que Equipes com Polyrepo Batem Numa Parede de Coordenação aos 50 Engenheiros
O imposto de coordenação se acumula. Com 8 engenheiros, gerenciar quatro repositórios é irritante, mas viável. Com 50, vira trabalho de meio período para várias pessoas.
Sinais concretos de que o overhead de coordenação do polyrepo se tornou estrutural:
Sua equipe de plataforma mantém um repositório de bibliotecas compartilhadas que ninguém tem ownership claro
O versionamento entre serviços divergiu tanto que incrementar a biblioteca compartilhada é um projeto de duas semanas
Um engenheiro novo não consegue ser produtivo sem entender quais dos seus 23 repositórios clonar primeiro
Patches de segurança em dependências compartilhadas exigem PRs coordenados em dezenas de repositórios, com uma planilha de rastreamento
Nenhum desses é uma patologia inventada. São failure modes documentados de equipes que chegaram a 80 engenheiros e olharam para trás para suas decisões de repositório com arrependimento.
Polyrepo funciona quando as equipes são genuinamente independentes: ciclos de release diferentes, stacks tecnológicas diferentes, rotações de plantão diferentes. Quando as equipes compartilham código suficiente para que uma mudança num serviço exija raciocinar sobre outros três, o isolamento que o polyrepo comprou se torna o mecanismo que torna a coordenação dolorosa.
O sinal organizacional: conte quantos canais no Slack existem especificamente para coordenar releases cross-repo. Se a resposta for mais de zero, você já começou a pagar o imposto de coordenação de forma consistente.
O Custo Real do Monorepo no Percentil 95
Os dados do P90 da Faros AI são instrutivos: 8,6 dias para PRs de monorepo no percentil 90. Isso não é uma equipe lenta: é a consequência estrutural de grandes mudanças cross-cutting exigindo coordenação entre múltiplos code owners, matrizes de CI mais amplas e ciclos de revisão que atravessam fronteiras organizacionais.
O Google tem o Bazel. A Meta construiu o Buck. O Nx Cloud e o Turborepo remote cache existem porque o investimento em tooling para fazer um monorepo performar não é trivial. Um monorepo com 200 engenheiros sem seleção de build apenas para partes afetadas, cache distribuído e merge queues automatizadas produz runs de CI de 45 minutos em PRs que tocam uma função utilitária compartilhada.
O custo de tooling é real e rotineiramente subestimado. Equipes que operam monorepos com sucesso em escala geralmente contrataram engenheiros de plataforma especificamente focados nessa infraestrutura. Retrofitar tooling de monorepo num codebase crescente enquanto também entrega produto é um dreno que aparece na frequência de deployment antes de aparecer num post-mortem.
Se sua equipe de plataforma já está sobrecarregada, adicionar manutenção de tooling de monorepo é um compromisso significativo: não uma escolha de configuração.
A Regra dos 30% que Equipes de Alta Performance Usam de Verdade
Uma heurística útil de equipes que tomaram essa decisão deliberadamente: se mais de 30% das suas features exigem mudanças em múltiplas fronteiras de serviço, o overhead de coordenação de um polyrepo eventualmente vai exceder o investimento em tooling de um monorepo bem gerenciado.
Abaixo de 30%, onde a maioria das organizações de microsserviços está, os benefícios de isolamento do polyrepo geralmente superam o imposto de coordenação. Mudanças cross-service acontecem, mas não com frequência suficiente para que o tooling compartilhado se pague mais rápido do que o isolamento faz.
Isso é mensurável. Analise os últimos seis meses de PRs merged e conte quantos exigiram mudanças em mais de um repositório para entregar uma única feature visível ao usuário. Esse ratio é o seu input. Não vai ser preciso com uma casa decimal, mas vai ser direcional, e direcional é suficiente para parar o debate de rodar com base em preferência de equipe.
Uma equipe com taxa cross-service de 12% não precisa de monorepo. Uma equipe em 38% e crescendo está pagando um imposto de coordenação que vai continuar se acumulando.
Como a Estratégia de Rollout Muda o Cálculo
Há uma dimensão dessa decisão que quase não recebe cobertura: o seu primitivo de rollout.
Se você executa rollouts baseados em porcentagem com SLO gates, entregando uma feature para 5% do tráfego, observando error budgets e depois expandindo progressivamente, seu cálculo de blast radius muda dependendo de se a feature abrange um ou vários serviços.
Num polyrepo, um rollout de feature multi-serviço exige coordenar o estado de rollout entre serviços. O serviço A pode estar em 20% enquanto o serviço B ainda está em 0%, criando estados inconsistentes genuinamente difíceis de raciocinar sob condições de incidente. Feature flags ajudam, mas você ainda está gerenciando estado de flag cross-service sem uma única fonte da verdade para o progresso do rollout.
Num monorepo com commits atômicos, a feature pousa de forma consistente entre serviços. O rollout ainda pode ser baseado em porcentagem no nível de infraestrutura, mas o código é consistente a partir do momento em que o deploy acontece. Seus SLO gates disparam contra um estado coerente.
Equipes que fazem muitas features atômicas multi-serviço, executando rollouts progressivos com rollback automatizado em violação de SLO, frequentemente descobrem que a consistência do monorepo elimina uma categoria inteira de incidente que o polyrepo não tem um nome claro: o incidente de divergência de estado cross-service que parece um bug, mas é na verdade um problema de coordenação de deployment.
O Que o Post-mortem Vai Dizer
A maioria das organizações de engenharia acaba num híbrido que ninguém chama de híbrido porque soa como uma saída arquitetural.
Um ou dois monorepos para superfícies de produto fortemente acopladas. Repositórios separados para serviços genuinamente autônomos com ciclos de deployment independentes, sua própria rotação de plantão e uma equipe que não precisou coordenar uma mudança de biblioteca compartilhada em seis meses.
O sinal para revisitar seu setup atual:
A frequência de mudanças cross-service cruzou 30% e os runtimes de CI estão se acumulando
Você contratou engenheiros de plataforma com capacidade para investir em tooling de monorepo
Um incidente de blast radius revelou que seu isolamento de polyrepo era falso: os serviços estavam compartilhando infraestrutura suficiente para que o isolamento fornecesse conforto, não segurança
O sinal de que a decisão está boa por enquanto:
As equipes são genuinamente independentes e o overhead de coordenação é baixo
Seu pior incidente não foi causado por drift de dependência cross-service
A capacidade de platform engineering não existe para manter tooling de monorepo sem desacelerar a entrega de produto
O post-mortem vai dizer em qual desses você está realmente vivendo. Esse documento costuma ser mais honesto do que o architecture decision record que precedeu o sistema que ele descreve.