Microsserviços: quando ajudam e quando são armadilha

Poucas decisões de arquitetura foram tão mal copiadas. Empresas de cinco desenvolvedores quebraram sistemas que funcionavam em vinte serviços, porque grandes empresas de tecnologia fizeram isso — ignorando que elas fizeram por um motivo que não se aplicava.

Vale entender qual é esse motivo, porque ele é a chave da decisão inteira.

O problema que microsserviços resolvem

Não é técnico. É organizacional.

Quando muitos times trabalham no mesmo código, eles param uns aos outros. Um time espera o outro para fazer deploy. Uma mudança em um módulo quebra o teste de outro. A coordenação para subir uma versão envolve gente demais. O gargalo deixa de ser a capacidade de escrever código e passa a ser a capacidade de coordenar.

Microsserviços resolvem isso dando a cada time um pedaço com fronteira própria, que ele entrega no ritmo dele, sem pedir licença.

A consequência direta e frequentemente ignorada: se você tem um time, não tem esse problema. E, sem esse problema, você está pagando o custo da solução sem receber o benefício.

O que eles custam de verdade

A lista que raramente aparece na apresentação:

A rede entra no caminho. O que era uma chamada de função vira uma chamada de rede — com latência, com possibilidade de falha, com timeout para configurar e retentativa para pensar. Uma operação que tocava três módulos agora depende de três serviços estarem no ar.

A transação some. Em monolito, uma operação que altera várias coisas ou acontece inteira ou não acontece. Distribuída, isso deixa de existir: é preciso desenhar consistência eventual, compensação, idempotência. É a parte mais difícil e a mais subestimada.

O diagnóstico fica caro. "Está lento" deixa de ter resposta óbvia. Sem rastreamento distribuído, investigar é eliminar serviço por serviço. Rastreamento deixa de ser luxo e vira requisito.

A operação multiplica. Vinte serviços são vinte pipelines, vinte conjuntos de métricas, vinte deploys, vinte dependências para atualizar. Isso exige plataforma — e plataforma exige gente.

Os dados se fragmentam. Cada serviço com o próprio banco é a recomendação clássica, e significa que relatórios que cruzam domínios ficam difíceis. Surge a necessidade de replicar dados, de montar uma camada analítica, de manter consistência entre cópias.

As versões precisam conviver. Serviços são atualizados em momentos diferentes, então versões diferentes de contrato coexistem. Mudança incompatível de API vira incidente de produção.

Monolito modular: a opção esquecida

A discussão costuma ser apresentada como binária, e o meio é onde a maioria deveria estar.

Monolito modular é um único artefato implantado, organizado internamente em módulos com fronteiras claras: cada um com o próprio domínio, comunicando-se por interfaces definidas, sem acessar diretamente as tabelas do outro.

Você ganha:

Fronteiras explícitas, que é o benefício de desenho dos microsserviços.
Deploy único, simples de operar.
Transação de verdade, com garantia de consistência.
Diagnóstico direto — uma pilha de chamadas, um log.
Refatoração barata, porque mover código entre módulos não quebra contrato de rede.

E, principalmente: quando um módulo realmente precisar virar serviço separado, a fronteira já existe. Extrair um módulo bem delimitado é trabalho conhecido; quebrar um monolito emaranhado é projeto.

Essa é a recomendação que mais damos: comece modular, extraia por necessidade.

Quando microsserviços compensam

Critérios concretos, não aspiracionais:

Vários times que se atrapalham mutuamente no mesmo código. Este é o critério principal.
Partes com perfil de escala muito diferente — um componente que precisa de dez vezes mais capacidade que o resto, e escalar o sistema inteiro para atendê-lo é desperdício.
Requisitos técnicos divergentes em partes distintas: uma precisa de outra linguagem, de outro banco, de outro ciclo de atualização.
Domínios com ciclo de vida independente, que mudam em ritmos diferentes.
Existe plataforma e gente para operar. Sem isso, a complexidade recai sobre quem deveria estar escrevendo produto.

Se menos de dois desses forem verdade, provavelmente não é a hora.

Os sinais de que foi armadilha

Quando a decisão foi prematura, os sintomas são reconhecíveis:

Monolito distribuído: os serviços são separados mas precisam ser implantados juntos, porque qualquer mudança afeta vários. Você pagou o custo e não ganhou a independência.
Serviço que só chama outro serviço, sem lógica própria.
Banco compartilhado entre vários serviços, acessado diretamente. A fronteira é ilusória.
Mais tempo em infraestrutura do que em produto.
Nenhum deploy independente de fato — na prática, sobe tudo junto.
Diagnóstico que leva horas para qualquer problema.

O primeiro item é o mais comum e o pior dos dois mundos.

Como decidir

Quatro perguntas, em ordem:

Quantos times mexem neste código? Um time → monolito modular.
Alguma parte precisa escalar muito diferente do resto? Se sim, extraia essa parte, não tudo.
Existe quem opere a plataforma? Se não, cada serviço novo é dívida operacional.
As fronteiras do domínio estão claras? Se não, separar agora cria fronteiras erradas — e fronteira errada em rede é muito mais cara de corrigir que em código.

A quarta é a mais importante e a menos considerada. Você precisa entender o domínio antes de desenhá-lo em serviços; e entender o domínio geralmente exige tê-lo construído primeiro.

Se for seguir esse caminho

O que precisa existir antes, não depois:

Rastreamento distribuído. Sem ele, o diagnóstico é inviável.
Log centralizado com identificador de correlação atravessando os serviços.
Testes de contrato entre serviços que se comunicam — é o teste de melhor retorno nessa arquitetura.
Versionamento de API com compatibilidade para trás, sempre.
Pipeline por serviço, automatizado.
Padrão de resiliência: timeout, retentativa com espera crescente, e interrupção de circuito para não propagar falha.
Fila de descarte monitorada, porque mensagem que falha em silêncio é o bug mais difícil dessa arquitetura.

E um conselho de sequência: extraia um serviço, opere por três meses, e só então extraia o segundo. Quem quebra tudo de uma vez descobre os problemas todos ao mesmo tempo.

Erros comuns

Adotar por modismo, sem o problema organizacional que justifica.
Quebrar o monolito inteiro de uma vez.
Separar serviços mantendo banco compartilhado acessado diretamente.
Criar serviço que só repassa chamada.
Não implantar rastreamento antes de distribuir.
Mudança incompatível de API sem versionamento.
Nenhum teste de contrato entre serviços.
Sem timeout e retentativa, propagando falha em cadeia.
Definir fronteiras antes de entender o domínio.
Confundir "temos containers" com "temos microsserviços".
Gastar mais tempo em infraestrutura do que em produto.

A resposta que serve para a maioria

Comece com monolito modular bem organizado. Instrumente desde cedo. Quando um módulo específico demonstrar necessidade real — escala própria, time próprio, requisito técnico divergente —, extraia aquele módulo.

Essa abordagem entrega quase todo o benefício de desenho sem o custo operacional, e mantém aberta a porta para distribuir quando houver motivo.

Microsserviços são uma solução cara para um problema caro. Vale ter o problema antes de comprar a solução.

Onde a Solvefy/Cloud entra

Atuamos nos dois lados dessa decisão. Para quem está avaliando, fazemos a leitura honesta: quantos times, qual perfil de escala, qual maturidade de plataforma — e com frequência a recomendação é mais simples do que o time esperava. Para quem já distribuiu e está sofrendo, arrumamos a base que faltou: rastreamento distribuído, log correlacionado, testes de contrato, versionamento de API, padrões de resiliência e pipeline por serviço. E conduzimos extração gradual quando a separação precisa mesmo acontecer.

Está considerando quebrar o seu sistema em serviços? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.