Monólito modular ou microsserviços? Como decidir

TL;DR

Você vai começar um produto e alguém já soltou a palavra “microsserviços” na reunião. Segura. Monólito modular é uma aplicação que roda como um processo só e faz um deploy só, mas por dentro é dividida em módulos com fronteiras claras e dependências explícitas entre eles. Microsserviços quebram esses módulos em serviços separados que rodam sozinhos e conversam pela rede.

Resposta curta, e é a que eu dou pra quase todo fundador que me pergunta: no começo, monólito modular quase sempre. Microsserviços resolvem um problema de escala de time e de operação que você provavelmente ainda não tem. E quando você tiver, o monólito bem fatiado deixa você dividir sem reescrever tudo.

O que cada um resolve de verdade

A diferença central não é código, é topologia de deploy. O monólito modular te dá organização interna dentro de um processo só. Microsserviços te dão isolamento de deploy e de falha, pagando com complexidade de operação: rede, latência, consistência eventual e observabilidade distribuída. Você troca um problema de disciplina de código por um problema de infraestrutura.

Notem: as duas arquiteturas podem ter exatamente as mesmas fronteiras internas. Um monólito modular com módulos bem separados e um sistema de microsserviços podem desenhar o mesmo diagrama de caixinhas. A diferença é o que existe entre as caixinhas. No monólito, é uma chamada de função. Nos microsserviços, é uma chamada de rede que pode falhar, atrasar ou voltar pela metade.

Microsserviço não é uma arquitetura melhor. É um custo de operação que você aceita pagar em troca de independência de deploy.

Por que microsserviços cedo quase sempre é a conta errada

Começar por microsserviços é pagar o pedágio antes de pegar a estrada. Você herda deploy distribuído, contratos de rede entre serviços, monitoramento espalhado e a alegria de debugar um bug que atravessa quatro serviços. Tudo isso antes de ter o problema que microsserviço resolve, que é organizacional: gente demais no mesmo codebase.

O ponto que quase ninguém fala: microsserviço é uma solução pra problema de time, não de software. A independência de deploy só vira vantagem real quando você tem equipes suficientes pra que um deploy comum vire gargalo. Com cinco pessoas, ninguém está brigando pela fila de deploy. Já vi time importar essa dor inteira sem levar junto nenhum pedaço do benefício.

“Mas o Netflix e o Uber rodam em microsserviços.”

ABSOLUTAMENTE. E eles chegaram lá com centenas de engenheiros, depois que o monólito virou o gargalo real de dezenas de times pisando no pé um do outro. Copiar a arquitetura de saída deles no seu dia 1 é vestir a roupa de quem já correu a maratona antes de sair do sofá. Não é sobre a solução ser ruim. É sobre o problema não ser o seu ainda. Martin Fowler chama isso de começar pelo monólito: a maioria dos casos de sucesso com microsserviços começou como monólito que foi dividido, não nasceu fatiado.

O que o monólito modular te dá sem cobrar o pedágio

Ele te dá fronteira sem rede no meio. Você separa o código em módulos com contratos explícitos, cada um dono do seu domínio, mas todos no mesmo processo. Refatorar uma fronteira é mover código e ajustar uma assinatura, não renegociar uma API entre dois serviços que fazem deploy em ritmos diferentes.

O segredo é tratar as fronteiras internas com a mesma seriedade que você trataria uma fronteira de rede. Módulo só fala com módulo pelo contrato público. Nada de um puxar tabela do banco do outro por baixo do pano. Se você mantém essa disciplina, extrair um módulo pra virar serviço depois vira uma operação cirúrgica, porque o corte já está desenhado. Se você não mantém, vira o que a gente chama de big ball of mud: uma bola de lama onde tudo depende de tudo e mexer num canto quebra outro do lado oposto.

A escolha fica mais clara olhando o que realmente muda entre as duas, em vez do hype:

Quando dividir de verdade

Divida por dor observada, nunca por previsão. O gatilho pra extrair um serviço não é achar que um dia vai precisar. É bater numa parede concreta que o monólito não resolve. Enquanto a parede não aparece, quebrar cedo só adianta o custo e adia o produto.

Os sinais reais que justificam extrair um pedaço:

• Escala de carga desigual. Um módulo específico consome recurso num perfil completamente diferente do resto, e replicar o monólito inteiro pra aguentar só ele sai caro. Aí faz sentido isolar aquele módulo pra escalar sozinho.
• Escala de time. Você tem gente demais no mesmo codebase e o deploy virou uma fila com engarrafamento. Times independentes precisando de deploy independente é o motivo clássico e legítimo.
• Isolamento de falha ou de compliance. Um componente não pode cair junto com o resto, ou precisa de fronteira dura por regulação. Rede vira uma barreira que a chamada de função não te dá.
• Tecnologia diferente de propósito. Aquele pedaço específico pede outra linguagem ou runtime por um motivo técnico honesto, não por preferência.

Fora esses casos, o monólito modular ainda é o certo. E o melhor: como as fronteiras já existem, você extrai o serviço no dia que a dor aparecer, sem parar tudo pra reescrever.

A hora de quebrar o monólito é quando ele começa a doer, não quando você imagina que um dia vai doer.

Onde cada escolha quebra

Nenhuma das duas é bala de prata, e fingir que existe a arquitetura perfeita seria desonesto.

• Monólito modular quebra na indisciplina. Se o time não respeita as fronteiras, os módulos vazam um pro outro e vira o big ball of mud. É o mesmo fim de quem herda um MVP vibe-coded pra escalar e descobre que não tinha fronteira nenhuma. A arquitetura depende de gente que segura a linha, e isso exige revisão e critério, não boa vontade.
• Monólito modular quebra na escala de time grande. Passou de um certo número de squads no mesmo codebase e a fila de deploy vira gargalo real. Aí a divisão deixa de ser opcional.
• Microsserviços quebram quando adotados cedo demais. Sem plataforma de deploy, observabilidade e gente que saiba operar isso, você não constrói microsserviços. Você constrói um monólito distribuído, o pior dos dois mundos: os serviços são acoplados como um monólito mas falham como uma rede, então você paga o custo distribuído sem ganhar a independência.
• Microsserviços quebram no custo escondido. Cada serviço novo é mais deploy, mais monitoramento, mais superfície de falha. Num time pequeno, esse custo consome o tempo que deveria estar indo pro produto.

A régua que eu uso é seca. Se você tem menos de umas duas dezenas de engenheiros e ainda está achando o encaixe do produto, comece monólito modular e trate as fronteiras com rigor. Divida um serviço no dia que uma dor concreta aparecer, não antes. Microsserviço desde o dia 1 é decisão que eu penso três vezes antes de tomar, porque o custo chega imediato e o benefício chega talvez.

Perguntas frequentes sobre monólito modular e microsserviços

Monólito modular é a mesma coisa que monólito?

Não. O monólito tradicional, o tal “big ball of mud”, também roda como um processo só, mas por dentro é uma bagunça sem fronteira: tudo acessa tudo. O monólito modular roda igual por fora, num deploy só, mas por dentro tem módulos com contratos claros e dependências explícitas. A diferença não está no deploy, está na disciplina interna.

Dá pra migrar de monólito modular pra microsserviços depois?

Sim, e é justamente esse o argumento a favor dele. Se os módulos já têm fronteiras bem definidas e só conversam pelos contratos públicos, extrair um deles pra virar serviço independente é uma operação localizada. O corte já está desenhado. Quem sofre na migração é quem tem um monólito sem fronteira, porque aí precisa primeiro organizar a casa pra só depois dividir.

Quando microsserviços fazem sentido desde o início?

Quase nunca num produto novo. A exceção honesta é quando você já tem, no dia 1, um time grande dividido em squads, um requisito duro de isolamento de falha ou compliance, ou um componente com perfil de escala tão diferente que precisa viver separado. Se nada disso é verdade, adotar microsserviços cedo é pagar um custo de operação sem o problema que o justifica.

Monólito modular escala?

Escala mais do que a maioria das pessoas imagina. Você replica o processo inteiro atrás de um load balancer e vai longe assim, especialmente com o banco bem cuidado. O limite do monólito modular raramente é de carga. Costuma ser de organização de time. Quando o gargalo vira “gente demais no mesmo deploy”, aí a conversa muda.

Qual arquitetura escolher pra um MVP?

Monólito modular, na quase totalidade dos casos. Ele te dá velocidade pra chegar no mercado com a organização interna que evita a bola de lama, e deixa a porta aberta pra dividir depois. Separar o que é essencial do que dá pra cortar importa mais nessa fase do que o desenho de topologia. A arquitetura certa é a do seu estágio, não a da palestra que você assistiu.

Escolha a arquitetura do seu estágio, não a da conferência

Quase toda discussão de monólito contra microsserviços começa errada porque trata como uma escolha de arquitetura ideal, no vácuo. Não é. É uma escolha de estágio. A pergunta não é qual é a arquitetura mais moderna. É qual problema você tem hoje e qual você vai ter em seis meses.

No começo, o seu problema é chegar no mercado com um produto que funciona e não vira lixo na primeira mudança. Monólito modular resolve isso e ainda deixa a saída aberta. Microsserviço resolve um problema de escala de time e de operação que, com sorte, você vai ter daqui a um ou dois anos. Otimizar hoje pra um problema que talvez chegue lá na frente é o jeito mais elegante de não entregar coisa nenhuma agora.

É por isso que a gente começa todo produto pela arquitetura do estágio certo: uma esteira que estima e entrega sem te vender complexidade que você ainda não precisa carregar.

Escolha a dor que você quer resolver hoje. A arquitetura sai dela, não da moda.