# Monorepo vs Polyrepo: Qual é a Escolha Certa para Seu Time? URL: https://formula.dog/pt/journal/monorepo-vs-polyrepo-escolha-time Type: blog Locale: pt Published: 2026-08-29 Updated: 2026-09-02 --- > Monorepo versus polyrepo depende de quão acoplado está seu código. Uma decisão que menos importa o número de repositórios e mais sobre se seus times precisam se mover juntos. Monorepo vs polyrepo é um debate que volta à tona toda vez que seu time de engenharia cresce mais rápido que os tempos de compilação. A resposta curta: um monorepo vence quando os times compartilham código regularmente e coordenam mudanças num espaço comum; um polyrepo vence quando os times são genuinamente independentes e fazem deploy sem nunca ficar esperando um pelo outro. Tudo no meio depende de quão acopladas suas arquiteturas realmente estão, e quanto overhead de coordenação seu time está disposto a absorver. Este artigo percorre os trade-offs reais, os sinais que apontam para um lado ou outro, e um framework prático para tomar a decisão. ## A Verdadeira Questão é Sobre Acoplamento, Não Sobre Número de Repositórios A maioria dos debates monorepo versus polyrepo começa com a pergunta errada. O número de repositórios não é o problema. O problema é se seus times precisam se mover juntos. Se as mudanças do Time A rotineiramente exigem que o Time B atualize algo no mesmo ciclo de release, você tem trabalho fortemente acoplado. Um repositório para isso é quase sempre a resposta mais limpa. Se o Time A e o Time B fazem deploy em seus próprios cronogramas, tocam partes diferentes do sistema e nunca ficam esperando um pelo outro, repositórios separados fazem sentido genuíno. O pior resultado possível: dois repositórios separados para código que ainda precisa fazer deploy junto. Você fica com todo o custo de coordenação de um monorepo, sem nenhum dos benefícios. Seus times acabam abrindo PRs no repositório A e no repositório B simultaneamente, rezando para que ambos passem na CI ao mesmo tempo. Esse padrão é surpreendentemente comum em organizações que escolheram polyrepo cedo e depois deixaram seus serviços ficarem mais interdependentes do que planejado originalmente. O primeiro passo antes de escolher qualquer coisa é desenhar um simples mapa de dependências. Liste cada serviço ou pacote que você possui e desenhe setas onde um depende do outro. Se as setas formarem um cluster denso, aquele cluster deve estar em um repositório. ![Software development team gathered around a whiteboard reviewing code architecture diagrams](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/be767c-img-1-inline.webp) ## Por Que Google, Meta e Microsoft Escolheram Monorepos em Escala Google mantém a maioria de seu código em um único repositório estimado em mais de 80 TB de dados e 2 bilhões de linhas de código. Meta e Microsoft fazem o mesmo para suas superfícies de produto central. Isso não é porque grandes empresas amam complexidade, é porque em escala, manter dependências em sincronização entre centenas de repositórios se torna um problema de engenharia em tempo integral. Uma única mudança de API em uma biblioteca compartilhada pode exigir atualizações coordenadas em 40 repositórios diferentes. Em um monorepo, isso é um pull request, uma review, um merge, um rollback se algo der errado. De acordo com pesquisa publicada pela Sourcegraph, 63% das empresas com 50 ou mais desenvolvedores agora usam um monorepo para pelo menos parte de sua base de código, crescimento acentuado em relação aos números de três anos atrás. O benefício concreto que mais importa: commits atômicos. Quando uma mudança crítica em sua API também exige atualizações de frontend e backend, um monorepo permite que você desembarque as três mudanças em um PR, teste-as juntas e faça rollback de todas as três como uma unidade se algo der errado. Com polyrepo, você abre três PRs separados, espera por três ciclos separados de review, e gerencia uma janela onde seus serviços estão rodando versões incompatíveis. Um time de engenharia reportou passar de deployments ocasionais para mais de 40 releases de aplicativos por semana após migrar seus pacotes de frontend para um monorepo Nx. Atualizações de Angular que anteriormente levavam meses se tornaram tarefas rotineiras que os times tratavam sem parar o outro trabalho. ## O Custo de Coordenação Oculto do Polyrepo Polyrepo tem vantagens reais que valem a pena levar a sério. Cada time controla seu próprio pipeline de CI/CD, seu próprio cadenciamento de release, seus próprios controles de acesso. Times de segurança e conformidade frequentemente preferem: acesso ao código pode ser restrito a pessoal nomeado numa base por-repositório, o que importa em indústrias reguladas. Componentes de código aberto vivem mais limpos em seus próprios repositórios públicos sem expor código interno. Para times que são genuinamente independentes, essas vantagens são reais. Um pequeno time de serviços que possui um pipeline de dados rodando em seu próprio cronograma e tocando nenhum código compartilhado tem pouco a ganhar ficando dentro de um monorepo maior. Mas organizações polyrepo silenciosamente acumulam custos que não apareceram na decisão original. Versionamento de dependências entre repositórios se torna sua própria disciplina. Uma biblioteca de utilidade compartilhada fica desatualizada em alguns repositórios enquanto continua atual em outros. Alguém tem que manter uma matriz de compatibilidade só para saber qual versão de qual biblioteca funciona com qual versão de qual serviço. Uma métrica que vale a pena conhecer: tempo mediano de ciclo de PR em monorepos ronda 19 horas, versus cerca de 2 horas em polyrepos. PRs em monorepos tendem a ser maiores porque tocam mais superfícies, o que desacelera a review. Mas quando uma mudança de polyrepo exige três PRs coordenados em três repositórios para desembarcar uma única feature, o tempo de ciclo agregado frequentemente excede a figura do monorepo de qualquer forma, com o risco adicionado de merges parciais deixando serviços em estados inconsistentes. O padrão que pega times desprevenidos: começamos com repositórios separados pela independência, mas agora cada release exige abrir PRs em quatro lugares. Naquele ponto você tem o pior dos dois mundos. ## Tempos de Compilação Pararam de Ser o Fator Decisivo em 2024 A objeção clássica aos monorepos era tempo de compilação. Se seu repositório tem 200 pacotes e você muda um arquivo, você realmente quer recompilar os 200? Esse argumento expirou em algum lugar por volta de 2022 a 2024, dependendo de sua stack. Ferramentas de build modernas usam cache com consciência de conteúdo. Elas apenas recompilam o que mudou, e pulam qualquer coisa com inputs idênticos. Uma mudança no pacote `payments` não dispara uma recompilação de `design-system` se nada em `design-system` mudou. GitHub Actions fornece 10 GB de armazenamento de cache gratuito antes de você precisar de uma solução de cache remoto pago. Turborepo lida bem com a maioria dos times de JavaScript e TypeScript até cerca de 20 pacotes. A configuração é um simples `turbo.json`, cache remoto funciona no Vercel gratuitamente ou auto-hospedado, e a curva de aprendizado é baixa o suficiente que um time pode ser produtivo dentro de um dia. Acima de 20 pacotes, ou quando o build abrange múltiplas linguagens, a abordagem mais estruturada do Nx tende a justificar a curva de aprendizado mais acentuada. Nx adiciona geração de código, distribuição automática de CI, e rastreamento de dependências de granulação fina que se torna cada vez mais valioso conforme o repositório cresce. Para muito grandes organizações rodando milhares de pacotes em múltiplas linguagens, Bazel (o sistema de build de código aberto do Google) é a única ferramenta projetada para aquela escala. O custo de setup é significativo e quase sempre exige um time dedicado de engenharia de plataforma. ![Multiple parallel deployment pipelines flowing from a central codebase, abstract DevOps infrastructure concept](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/6761f6-img-2-inline.webp) ## Quatro Perguntas que Resolvem o Debate para Seu Time Não há uma resposta universal correta, mas há um framework confiável. **1. Seus times compartilham código que muda frequentemente?** Se sim, um sistema de design compartilhado, uma biblioteca de cliente de API compartilhada, lógica de autenticação compartilhada, um monorepo é quase sempre a melhor escolha. Manter uma biblioteca compartilhada sincronizada entre múltiplos repositórios exige disciplina constante e quase sempre diverge. **2. Seus times fazem deploy independentemente?** Se o Time A faz deploy de seu serviço na terça e o Time B na quinta sem coordenação necessária, polyrepo ganha seu lugar. Se lançar um serviço exige um lançamento simultâneo de outro, aquele custo de acoplamento pertence à equação. **3. Quantos engenheiros estão tocando esta base de código?** Abaixo de 20 engenheiros, estrutura de repositório importa menos do que você pensa. Acima de 50, os custos de coordenação de polyrepo começam a se acumular visivelmente. Acima de 200, o caso para um monorepo se torna muito forte a menos que times sejam genuinamente isolados por produto e tecnologia. **4. Você tem requisitos de segurança ou conformidade que isolam código por time?** Em indústrias reguladas, finanças, saúde, alguns contextos governamentais, acesso ao código pode precisar ser restrito a pessoal nomeado. Esse constrangimento pode sobrepor as outras respostas. Se isolamento de código é um requisito de conformidade, polyrepo não é uma escolha, é um constrangimento. Se você respondeu sim à pergunta 1 e não à pergunta 4, um monorepo é quase certamente a chamada certa. Se você respondeu não à pergunta 1 e sim à pergunta 2, polyrepo é uma escolha defensável. Tudo mais é um julgamento. ## Aonde a Maioria dos Times em Crescimento Realmente Cai Muito poucas organizações de engenharia madura operam em qualquer extremo. O padrão que aparece mais frequentemente: um monorepo para o produto central (frontend, bibliotecas compartilhadas, serviços backend que dependem um do outro), e repositórios separados para componentes verdadeiramente independentes. Um pipeline de dados que roda em seu próprio cronograma e não compartilha código com o produto principal pertence fora do monorepo. Uma ferramenta interna mantida por um time de pessoa única pertence fora. Uma biblioteca de código aberto que precisa de visibilidade pública pertence fora. Isso não é um compromisso. É a resposta correta a uma pergunta que raramente tem uma resposta binária limpa. Mantenha as coisas juntas que precisam se mover juntas. Separe o que é genuinamente independente. A coisa importante é tomar a decisão deliberadamente, não por padrão. A maioria dos times que acabam com propagação de polyrepo não escolheu isso: eles começaram um serviço, depois outro, depois outro, e nunca pararam para perguntar se esses serviços precisavam viver juntos. ## A Ferramenta que Torna Qualquer Abordagem Realmente Funcionar **Para monorepos:** - Nx: conjunto de features mais forte, bom para builds polyglota e times acima de 20 pacotes. Curva de aprendizado mais acentuada mas escala mais longe. - Turborepo: mais simples para começar, excelente para times de JS/TS abaixo de 20 pacotes. Cache nativo do Vercel ou opções auto-hospedadas. - Bazel: para repositórios muito grandes multi-linguagem em escala empresarial. Investimento de setup significativo necessário. **Para polyrepos:** - Uma disciplina de versionamento para bibliotecas compartilhadas não é opcional. Sem versionamento semântico e um processo de changelog consistente, divergência de dependência se torna a norma dentro de seis meses. - Ferramental de CI/CD que dispara pipelines entre repositórios quando uma dependência compartilhada muda. GitHub Actions suporta isso via eventos `workflow_dispatch` e `repository_dispatch` entre repositórios. - Um registro de dependência (npm private registry, GitHub Packages, Artifactory) para gerenciar distribuição de pacotes compartilhados. Biscuit consegue buscar o arquivo de configuração. A chamada sobre qual usar ainda depende daquelas quatro perguntas. ![Developer working at dual monitor setup reviewing pull requests in a dark home office](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/47a076-img-3-inline.webp) ## FAQ ### Quando devo escolher um monorepo em vez de polyrepo? Escolha monorepo quando seus times compartilham código frequentemente e precisam coordenar mudanças no mesmo ciclo de release. Especialmente eficaz para produtos com frontend, backend e bibliotecas compartilhadas que evoluem juntos. ### Qual é o tamanho do time que justifica um monorepo? Abaixo de 20 engenheiros, a estrutura de repositório importa menos. Acima de 50, os custos de coordenação de polyrepo começam a ser significativos. Acima de 200, monorepo oferece benefícios claros de coordenação. ### As ferramentas modernas resolvem os problemas antigos de tempo de compilação? Sim. Turborepo e Nx resolvem a maioria dos problemas de build em monorepos. Turborepo funciona bem até 20 pacotes; Nx escala para centenas. Cache inteligente significa você só recompila o que mudou. ### Posso usar uma abordagem híbrida? Sim, é o padrão mais comum em organizações maduras: monorepo para o produto central, polyrepo para componentes genuinamente independentes. O importante é decidir deliberadamente, não por padrão. ### Como ferramentas de conformidade afetam essa decisão? Se você precisar de isolamento de código por time por compliance, polyrepo é um requisito, não uma escolha. Nesse caso, invista em versionamento semântico e CI/CD que coordene entre repositórios. ### Qual é o overhead real de coordenação em polyrepo? Tempo de ciclo de PR pode dobrar ou triplicar quando mudanças exigem edições em múltiplos repositórios. Além disso, divergência de versão de dependências e compatibilidade cruzada exigem disciplina constante. ### Monorepo exige ferramentas especiais ou pode ser git puro? Um monorepo funciona com git puro, mas ferramentas como Nx, Turborepo ou Bazel tornam a gestão muito mais prática. Elas oferecem cache inteligente, distribuição de CI e isolamento de packages.