De Monolito a Microserviços: O Caminho Real

A migração de monolito para microserviços é uma das decisões mais impactantes — e mais mal executadas — da engenharia de software. Depois de mais de 50 projetos de modernização em saúde, financeiro, indústria e governo, sabemos exatamente onde essas iniciativas quebram e o que separa os 30% que dão certo do resto.

Antes da Arquitetura, o Business Case

A pergunta certa não é "devemos usar microserviços?" — é "qual dor de negócio estamos resolvendo?". As respostas legítimas são mensuráveis:

• Time-to-market: o monolito trava entregas porque todo deploy é um evento de risco
• Escala seletiva: 5% do sistema concentra 80% da carga, mas hoje é preciso escalar (e pagar) tudo junto
• Autonomia de times: mais de 30 desenvolvedores no mesmo código, com filas de integração e conflitos constantes
• Risco concentrado: uma falha em módulo secundário derruba a operação inteira

Se nenhuma dessas dores existe com números, a migração é hype — e vai custar caro. Em vários diagnósticos, nossa recomendação foi não migrar: um monolito modular bem estruturado é a arquitetura certa para a maioria das empresas com times de até 20 engenheiros.

Por Que 70% Falham

Big Bang Rewrite

Reescrever tudo de uma vez, enquanto o sistema antigo continua evoluindo, é correr atrás de um alvo em movimento. Projetos com mais de 12 meses sem entrega incremental têm taxa de falha superior a 70% — e o custo não é só o projeto: é o roadmap congelado durante a reescrita.

Microserviços Prematuros

Microserviços trocam complexidade de código por complexidade operacional: rede, latência, consistência eventual, observabilidade distribuída. Sem maturidade de engenharia para operar isso, o resultado é um sistema mais frágil do que o monolito que ele substituiu.

O Monolito Distribuído

Quebrar o sistema sem entender as fronteiras do domínio produz o pior dos dois mundos: serviços que precisam mudar juntos, deploys coordenados, transações distribuídas. Toda a complexidade dos microserviços, nenhum dos benefícios.

O Caminho que Funciona

Strangler Fig, com Critério

Extraia gradualmente, mantendo o monolito vivo durante toda a transição. A escolha do primeiro módulo define o projeto: procure alto valor de negócio, baixo acoplamento com o resto e um dono claro no organograma. O primeiro serviço extraído é também o que valida a esteira inteira — CI/CD, observabilidade, rollback.

Domain-Driven Design como Bússola

Antes de qualquer decisão técnica, invista uma ou duas semanas em Event Storming com quem opera o negócio. As fronteiras naturais do sistema (bounded contexts) aparecem no mapa de eventos — e são elas, não o organograma da TI, que definem os serviços. Na transição, uma camada anticorrupção protege o serviço novo dos modelos do legado.

Dados: a Parte que Ninguém Conta

Separar o código é a parte fácil. O teste real é o banco de dados:

• Database per service é o destino, mas o caminho tem fases: primeiro esquemas separados, depois bancos separados
• Evite dual-write: escrever nos dois bancos "por segurança" gera inconsistência silenciosa. Use o padrão Outbox ou captura de dados de mudança (CDC) para sincronizar com garantias
• Relatórios e consultas cruzadas: resolva com projeções dedicadas ou um data lake — não com serviços consultando o banco uns dos outros

Infraestrutura Primeiro

Antes de extrair o primeiro serviço: observabilidade completa (logs, métricas, traces distribuídos), CI/CD automatizado, API gateway e feature flags para ativar e reverter mudanças sem deploy.

A Lei de Conway Trabalha Contra Você — ou a Favor

A arquitetura sempre converge para a estrutura de comunicação dos times. Se os times não forem reorganizados em torno dos novos serviços, com donos claros, o sistema volta a se acoplar. Modernização de arquitetura sem desenho organizacional é metade de um projeto.

Métricas de Sucesso

• Valor entregue em produção a cada 2-4 semanas, desde o primeiro mês
• Incidentes caindo progressivamente no monolito conforme os módulos críticos saem
• Lead time dos serviços extraídos visivelmente menor que o do legado
• Times operando seus serviços com autonomia real de deploy

O Bônus que Ninguém Menciona: Prontidão para IA

Um sistema modernizado, com APIs claras e eventos bem definidos, é o pré-requisito para a próxima onda: automação e agentes de IA que executam processos de ponta a ponta. O legado monolítico não conversa com agente nenhum. Cada serviço extraído com contrato claro é um ponto de integração pronto para IA.

Conclusão

Modernização bem-sucedida é uma maratona com entregas de sprint: visão de longo prazo, valor a cada ciclo. A diferença entre os 30% que chegam lá e o resto costuma ser ter ao lado quem já percorreu o caminho — e sabe onde ficam os precipícios. É esse o papel que assumimos nos projetos de modernização que lideramos.