Não existe bala de prata. Existe contexto.

Poucas discussões técnicas geram tanta paixão (e tanto prejuízo) quanto essa. De um lado, o monolito, tratado injustamente como sinônimo de atraso. Do outro, os microsserviços, vendidos como passaporte automático para a escala. A verdade, como quase sempre em arquitetura de software, é menos glamourosa: cada um resolve um problema diferente, e escolher errado custa caro dos dois lados.

O que cada um é, sem caricatura

Monolito é uma aplicação implantada como uma unidade: um código-base, um deploy, um banco (em geral). Toda a lógica de negócio vive junta e conversa por chamadas internas, rápidas e transacionais.

Microsserviços quebram o sistema em serviços pequenos e independentes, cada um com seu deploy, seu banco e seu ciclo de vida, conversando por rede (APIs, filas, eventos).

A diferença central não é tamanho de arquivo: é unidade de implantação e autonomia de times.

O que os microsserviços cobram de pedágio

Martin Fowler, uma das maiores referências em arquitetura de software, mantém um alerta famoso: não considere microsserviços sem antes dominar pré-requisitos como provisionamento rápido, deploy automatizado e monitoramento maduro (MicroservicePrerequisites). Sem isso, você não ganha os benefícios, só herda os custos:

• Complexidade distribuída: chamadas que eram função viram rede, com latência, timeout, retry e falha parcial.
• Consistência de dados: transações que eram um COMMIT viram sagas e consistência eventual.
• Custo operacional: dezenas de pipelines, versões e dashboards no lugar de um.
• Custo cognitivo: ninguém mais enxerga o sistema inteiro na cabeça.

Sam Newman, autor de Building Microservices (O'Reilly), resume: microsserviços devem ser uma decisão consciente para resolver problemas específicos de escala organizacional, não um ponto de partida (samnewman.io).

E há o caso que virou lenda: em 2023, o time do Prime Video da Amazon publicou que migrou um workload de microsserviços de volta para um monolito e reduziu custos em 90%. Nem a Amazon usa microsserviços para tudo.

Quando o monolito é a escolha certa

• Produto novo, mercado ainda em validação (a maioria dos casos).
• Time pequeno (uma ou duas equipes) que cabe num único código-base.
• Domínio ainda em mutação: as fronteiras entre módulos mudam toda semana.
• Orçamento de infraestrutura e operação enxuto.

O monolito moderno não é uma bola de lama: com módulos bem separados e fronteiras claras (o chamado monolito modular), ele entrega velocidade de desenvolvimento com portas abertas para extrair serviços no futuro. Fowler chama essa estratégia de MonolithFirst: comece junto, separe quando a evidência pedir.

Quando os microsserviços se pagam

• Times múltiplos pisando no mesmo código: deploys que se bloqueiam, filas de merge, releases coordenadas. A autonomia de deploy vira ganho real.
• Escala desigual: uma parte do sistema precisa de 50 instâncias e o resto de 2. Separar economiza.
• Requisitos díspares: um módulo precisa de latência mínima em Go, outro é um batch pesado em Python.
• Isolamento de falha e de risco: um domínio crítico que não pode cair junto com o resto.

A pergunta certa não é técnica, é organizacional

A Lei de Conway diz que sistemas espelham a estrutura de comunicação de quem os constrói. Na prática: a arquitetura certa depende mais do desenho dos seus times do que do seu volume de tráfego. Duas equipes? Dois ou três serviços grandes talvez bastem. Quinze equipes? A conversa muda.

Por isso, nosso roteiro em consultoria costuma ser:

1. Comece com monolito modular, fronteiras de domínio explícitas.
2. Meça as dores reais: tempo de deploy, conflitos entre times, gargalos de escala.
3. Extraia serviços cirurgicamente, um por vez, guiado por evidência e não por moda.

É o mesmo princípio do nosso processo de Discovery aplicado à engenharia: decidir com evidência, não com hype.

Precisa decidir agora?

Se você está desenhando um produto novo, avaliando quebrar um monolito ou sofrendo com uma migração de microsserviços que saiu do controle, esse é exatamente o tipo de decisão que atacamos no nosso serviço de Arquitetura de Software: avaliamos contexto, times e trajetória de crescimento antes de recomendar qualquer desenho.

Quer uma leitura rápida do seu cenário? Converse com a IA da Rabelo Digital, aqui no canto da tela. Descreva seu sistema e ela indica os pontos de atenção. Sem formulário, sem espera.

---

Leia também

• 5 decisões arquiteturais que você vai se arrepender
• Event-Driven Architecture explicada
• Clean Architecture na prática