Em algum WeWork agora mesmo, uma startup de duas pessoas com zero usuários está debatendo se deve usar Kafka ou RabbitMQ para seu event bus. O MVP deles nem existe ainda, mas o diagrama de arquitetura tem 14 serviços, 3 filas de mensagens e um service mesh. Eles vão ficar sem dinheiro antes de ficar sem infraestrutura para configurar.
Esta é a armadilha dos microserviços, e ela mata startups com frequência alarmante.
O padrão se repete: um time técnico lê sobre como Netflix, Spotify ou Uber decompuseram seus monolitos em microserviços. Eles concluem que microserviços são a arquitetura "certa." Eles constroem seu MVP como microserviços desde o primeiro dia. Seis meses depois, gastaram 70% do tempo de engenharia em infraestrutura e 30% no produto. Não têm usuários, não têm receita, e têm uma arquitetura projetada para problemas que não possuem.
Aqui está a verdade desconfortável: 90% das startups deveriam começar com um monolito. Os outros 10% provavelmente também.
Por Que Microserviços Matam MVPs
O Imposto da Complexidade
Um monolito é uma aplicação, um deploy, um banco de dados, um conjunto de logs. Uma arquitetura de microserviços com 5 serviços é:
- 5 codebases separadas (ou um monorepo com 5 destinos de deploy)
- 5 pipelines de CI/CD para manter
- 5 conjuntos de variáveis de ambiente
- 5 health checks e dashboards de monitoramento
- Comunicação entre serviços (HTTP, gRPC ou filas de mensagens)
- Descoberta de serviços (DNS, load balancers ou service mesh)
- Rastreamento distribuído (porque debugar através de 5 serviços é impossível sem isso)
- Consistência de dados (porque transações entre serviços exigem sagas ou consistência eventual)
Cada serviço adiciona overhead operacional. Para um time de 2–5 desenvolvedores entregando um MVP, esse overhead consome 40–60% das horas de engenharia disponíveis. Isso não é um erro de arredondamento — é a diferença entre lançar em 8 semanas e lançar em 8 meses.
O Imposto de Sistemas Distribuídos
Microserviços transformam toda chamada de função em uma chamada de rede. Chamadas de rede falham. Dão timeout. Retornam dados obsoletos. Chegam fora de ordem. Toda interação entre serviços introduz modos de falha que não existem em um monolito.
Em um monolito, uma chamada de função para calcular preço leva microssegundos e nunca falha (a menos que o processo inteiro crashe). Em microserviços, o mesmo cálculo exige uma requisição HTTP para o serviço de preços, que pode estar:
- Temporariamente indisponível (deploy em andamento)
- Lento (cold start, contenção de recursos)
- Retornando dados em cache de 5 minutos atrás
- Retornando um erro porque o pool de conexões do banco está esgotado
Agora multiplique isso por cada chamada entre serviços em cada requisição do usuário. Um único carregamento de página pode tocar 4–5 serviços, cada um com sua própria probabilidade de falha. Tratar todos esses modos de falha corretamente — retries, circuit breakers, fallbacks, timeouts — é uma disciplina de engenharia em tempo integral. Seu time de MVP não tem banda para isso.
O Imposto dos Testes
Testar um monolito: inicie a aplicação, rode os testes. Testar microserviços: inicie todos os serviços (ou faça mock deles), garanta que conseguem se comunicar, rode os testes, debuge falhas que são problemas de rede disfarçados de bugs de lógica.
Testes de integração entre microserviços são uma ordem de magnitude mais difíceis do que testar um monolito. Contract testing, consumer-driven contracts e ambientes de teste end-to-end adicionam ferramentas e processos que MVPs não precisam. Nosso guia de pipeline CI/CD cobre estratégias de teste, e para MVPs, a resposta é esmagadoramente: mantenha simples com um monolito.
O Imposto do Debug
Usuário reporta um bug: "Cliquei em enviar e nada aconteceu." Em um monolito, você verifica um stream de logs, encontra o erro, corrige. Em microserviços, você verifica 5 streams de logs, correlaciona request IDs entre serviços, descobre que o serviço de pagamento deu timeout esperando o serviço de inventário, que estava esperando o serviço de preços, que tinha um cache obsoleto. Debug leva 5x mais tempo. Todo bug se torna uma investigação de sistemas distribuídos.
A Vantagem do Monolito para MVPs
Velocidade de Iteração
Um monolito permite que você mude qualquer coisa em um único commit. Renomeie uma coluna do banco, atualize a API, corrija a UI — tudo em um pull request, uma review, um deploy. Em microserviços, a mesma mudança pode tocar 3 serviços e exigir deploys coordenados com compatibilidade retroativa.
Durante o desenvolvimento do MVP, você muda tudo constantemente. Mudanças de schema, redesigns de API, pivots de funcionalidade, revisões de UX — o produto inteiro está em fluxo. Um monolito acomoda fluxo. Microserviços resistem a ele. Ao construir em um cronograma de oito semanas, a capacidade de mudar de direção em horas ao invés de dias é existencial.
Menor Custo
Um servidor de aplicação custa menos que cinco. Um banco de dados custa menos que cinco. Um setup de monitoramento custa menos que cinco. Na fase de MVP, você está otimizando para runway — cada dólar economizado em infraestrutura é um dólar disponível para desenvolvimento de produto e aquisição de clientes.
Um MVP monolítico típico na Vercel ou Railway custa US$ 20–50/mês. A arquitetura equivalente em microserviços na AWS custa US$ 200–500/mês no mínimo, mais as horas de engenharia para gerenciá-la. Ao longo de uma fase de MVP de 6 meses, são US$ 1.000–3.000 em custos de infraestrutura desnecessários — e 200+ horas de engenharia em trabalho operacional desnecessário.
Debug Mais Fácil
Uma aplicação, um stream de logs, um debugger. Quando algo quebra, você coloca um breakpoint, percorre o código e encontra o problema. Sem rastreamento distribuído. Sem correlação entre serviços. Sem conversas sobre "qual serviço é dono desse bug?"
Onboarding Mais Simples
Um novo desenvolvedor entra na sua startup. Com um monolito: clone o repo, rode docker compose up ou pnpm dev, comece a codar. Com microserviços: clone 5 repos, entenda a topologia de serviços, configure comunicação entre serviços localmente, descubra qual serviço modificar e reze para o ambiente local espelhar produção.
Tempo de onboarding com monolito: horas. Com microserviços: dias a semanas. Para uma startup contratando seus primeiros 3–5 engenheiros, isso importa enormemente.
Quando Microserviços Realmente Fazem Sentido
Microserviços não são errados — são errados para MVPs. Fazem sentido quando:
1. Você Tem Product-Market Fit Comprovado
Uma vez que seu produto é estável e crescendo, decomposição se torna valiosa. Você sabe quais componentes mudam frequentemente, quais escalam independentemente e quais têm requisitos de confiabilidade diferentes. Decisões de decomposição baseadas em padrões reais de uso são sólidas. Decisões de decomposição baseadas em especulação não são.
Acompanhe suas métricas de product-market fit primeiro. Quando curvas de retenção se estabilizam, receita cresce consistentemente e pedidos de funcionalidades superam reclamações de arquitetura — aí microserviços se tornam uma conversa razoável.
2. Seu Time Excede 10 Engenheiros
Como Sam Newman argumenta em Building Microservices, microserviços são um padrão organizacional, não apenas técnico. Existem para permitir que times independentes façam deploy independentemente. Se você tem 3 desenvolvedores, deploy independente não tem significado — todos estão fazendo deploy da mesma coisa. Com 10+ engenheiros, ownership de serviço permite trabalho paralelo sem conflitos de merge e coordenação de deploy.
A regra de "two-pizza team" da Amazon não surgiu porque microserviços são tecnicamente superiores. Surgiu porque independência organizacional exige independência de serviços. Sem organização, sem necessidade de padrões organizacionais.
3. Componentes Precisam de Escalabilidade Independente
Se sua aplicação web processa 100 requisições/segundo mas seu pipeline de processamento de dados processa 10.000 eventos/segundo, rodá-los no mesmo processo desperdiça recursos. Decomponha quando requisitos de escalabilidade genuinamente divergem — não quando você imagina que podem divergir um dia.
4. Componentes Diferentes Precisam de Tecnologias Diferentes
Se seu web app é melhor construído em TypeScript mas seu pipeline de ML exige Python, a separação é natural. Arquiteturas poliglotas são uma razão legítima para fronteiras de serviço. Mas se tudo é TypeScript, o argumento poliglota não se aplica.
O Monolito Modular: O Melhor dos Dois Mundos
O monolito modular é a arquitetura que a maioria das startups deveria adotar e quase nenhuma adota. Combina a simplicidade de deploy de um monolito com a clareza organizacional de microserviços.
Como funciona:
- Aplicação única deployável
- Internamente organizada em módulos com fronteiras claras
- Cada módulo é dono da sua lógica de domínio, tabelas de banco e superfície de API
- Módulos se comunicam por interfaces bem definidas, não por acesso direto ao banco
- Módulos podem ser extraídos em serviços depois, se necessário
Esta é exatamente a abordagem que usamos na Meld, fundamentada em princípios de Domain-Driven Design. A plataforma de aviação AeroCopilot — um dos produtos SaaS mais complexos que construímos — roda como um monorepo com 18 pacotes. Não 18 microserviços. Não 18 destinos de deploy. Dezoito pacotes em uma única aplicação deployável com fronteiras claras entre domínios.
Esses 18 pacotes incluem:
- Schema de banco de dados e migrações (Prisma)
- Autenticação e autorização
- Lógica de domínio de planejamento de voo
- Processamento de dados meteorológicos
- Motor de cálculo de combustível
- Regras de conformidade regulatória
- Sistema de notificações
- Gerenciamento de conteúdo
- Analytics e relatórios
Cada pacote tem seus próprios tipos, sua própria lógica de negócio e sua própria suíte de testes. Eles se comunicam por interfaces TypeScript, não por chamadas HTTP. Uma chamada de função entre pacotes leva microssegundos, não milissegundos. Não há falhas de rede, overhead de serialização, pesadelos de transações distribuídas.
Se o processamento meteorológico do AeroCopilot eventualmente precisar escalar independentemente — porque processa 100x mais carga que planejamento de voo — extrair aquele pacote em um serviço separado é direto. A interface já existe. A fronteira já está limpa. A extração é uma mudança de deploy, não uma mudança de arquitetura.
Este é o insight chave — alinhado com o que Martin Fowler descreve em seu artigo seminal sobre microserviços: projete para modularidade, faça deploy como monolito. Você obtém os benefícios organizacionais de fronteiras de serviço sem o custo operacional de sistemas distribuídos. Quando precisar extrair um serviço, o design modular torna a extração barata. Mas você nunca paga o imposto de sistemas distribuídos até realmente precisar.
Implementando um Monolito Modular
Os passos práticos:
Defina contextos delimitados. Identifique os domínios de negócio distintos na sua aplicação. Cada domínio se torna um módulo. Use event storming para descobrir fronteiras colaborativamente.
Aplique fronteiras de módulo. Cada módulo expõe uma API pública (interfaces TypeScript ou uma camada de serviço). Nenhum módulo acessa diretamente tabelas de banco ou tipos internos de outro módulo. Regras de lint e testes de arquitetura garantem isso.
Use um monorepo. Ferramentas como Turborepo, Nx ou pnpm workspaces gerenciam monorepos multi-pacote. Cada módulo é um pacote com seu próprio
package.json, seus próprios testes e sua própria configuração de build. Nosso guia de arquitetura monorepo cobre o setup.Compartilhe por interfaces, não por implementações. O módulo de planejamento de voo não importa as queries de banco do módulo meteorológico. Ele importa uma interface
WeatherServicee chamagetWeatherForRoute(). Os detalhes de implementação ficam escondidos.Teste na fronteira. Cada módulo tem testes unitários para sua lógica interna e testes de integração para sua API pública. Se os testes de integração passam, o módulo está funcionando corretamente independente de mudanças internas.
O Caminho de Migração
Começar com um monolito não te prende a um monolito para sempre. O caminho de migração é bem entendido:
- Fase 1 (MVP): Monolito. Entregue rápido, itere constantemente, encontre product-market fit.
- Fase 2 (Crescimento): Monolito modular. Refatore em módulos claros com fronteiras aplicadas. É aqui que a maioria das empresas deveria ficar permanentemente.
- Fase 3 (Escala): Extração seletiva. Extraia módulos específicos em serviços quando — e somente quando — você tiver evidência concreta de que precisam de escalabilidade, deploy ou tecnologia independentes.
A maioria das empresas de sucesso nunca chega à Fase 3. Shopify roda um monolito modular que processa bilhões em transações. GitHub rodou um monolito por mais de uma década. Basecamp é um monolito desde 2004 e atende milhões de usuários. Stack Overflow famosamente roda em um punhado de servidores com arquitetura monolítica.
As empresas que chegam à Fase 3 — Netflix, Amazon, Uber — fizeram isso após anos de crescimento monolítico, com centenas de engenheiros e gargalos de escalabilidade concretos. Elas não começaram com microserviços. Elas conquistaram a necessidade deles.
O Framework de Decisão
Faça três perguntas:
- Você tem product-market fit? Não → Monolito. Sim → Talvez monolito modular.
- Você tem 10+ engenheiros? Não → Monolito. Sim → Monolito modular, considere extração seletiva.
- Você tem gargalos de escalabilidade concretos e medidos? Não → Não adicione serviços. Sim → Extraia o gargalo específico.
Se você respondeu "Não" a todas as três, você não precisa de microserviços. Você precisa entregar seu produto, encontrar clientes e provar seu modelo de negócio. Decisões de arquitetura feitas sem usuários são especulação. Especulação com custos de infraestrutura é desperdício.
Pare de over-engineering. Comece a entregar.