# Monorepo vs Polyrepo Comparação: Dados de 320 Equipes URL: https://upstreamapi.com/pt/journal/monorepo-vs-polyrepo-comparacao Type: blog Locale: pt Published: 2026-09-12 Updated: 2026-09-13 --- > Análise de dados reais sobre monorepo vs polyrepo: benchmarks de 320 equipes, blast radius, overhead de coordenação e a regra dos 30% para 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](https://www.faros.ai/blog/monorepo-vs-polyrepo-benchmark-data) 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. ![Engenheiro SRE monitorando métricas de deployment em estação de trabalho com múltiplos dashboards](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/6a5eb6-inline1.webp) ## 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. ![Diagrama de arquitetura em quadro branco mostrando estruturas de pipeline para monorepo e polyrepo](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/6dbec8-inline2.webp) ## 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. ## FAQ ### O que é melhor para startups em fase inicial: monorepo ou polyrepo? Para equipes pequenas (2 a 10 engenheiros), polyrepo costuma ser mais simples de operar. O custo de tooling de um monorepo bem mantido raramente se justifica antes de você ter dependências compartilhadas reais e mudanças cross-service frequentes. Comece com polyrepo e migre quando os dados de coordenação forçarem a decisão. ### Como calcular se minha equipe precisa de monorepo? Analise os últimos seis meses de PRs merged e calcule qual percentual exigiu mudanças em mais de um repositório para entregar uma única feature. Se esse ratio estiver acima de 30% e crescendo, o custo de coordenação do polyrepo provavelmente já supera o investimento em tooling de monorepo. ### Qual é o impacto real no tempo de ciclo de PR ao usar monorepo? Segundo análise da Faros AI com 320 equipes ao longo de 12 meses, a mediana de ciclo de PR em monorepos é de 19 horas contra 2 horas em polyrepos -- uma diferença de 9,5x. No P90, a diferença é de 8,6 dias (monorepo) contra 5,5 dias (polyrepo). Os dados refletem PRs típicos; mudanças cross-service em polyrepos também são lentas. ### Monorepo aumenta o blast radius em caso de bug em dependência compartilhada? Sim, no sentido de que o impacto é imediato e simultâneo em todos os serviços que importam a dependência afetada. Em polyrepo, o blast radius é diferido: cada serviço só é afetado quando faz upgrade. Para equipes com rollouts SLO-gated, polyrepo oferece uma janela de canary natural que monorepo não tem por padrão. ### Como Google e Meta conseguem operar monorepos em escala? Google usa Bazel e Meta construiu Buck, ambos sistemas de build customizados com cache distribuído, seleção de build apenas para partes afetadas e merge queues automatizadas. Essas ferramentas levaram anos para ser desenvolvidas. Empresas que adotam monorepo hoje têm acesso a alternativas como Nx Cloud e Turborepo, mas o investimento em plataforma ainda é substancial. ### Quando faz sentido migrar de polyrepo para monorepo? Os três sinais principais: (1) mais de 30% das suas features cruzam fronteiras de serviço; (2) você tem engenheiros de plataforma com capacidade dedicada ao tooling de monorepo; (3) um incidente de blast radius revelou que o isolamento do polyrepo era ilusório porque os serviços compartilhavam infraestrutura demais. Os três precisam estar presentes -- um ou dois raramente justificam a migração.