Chegamos ao encerramento da nossa jornada. Após cruzar os incentivos psicológicos do mercado de trabalho, a matemática rígida de redes, o desenho organizacional de Conway e a realidade financeira das nuvens públicas, precisamos traçar a estratégia prática para os projetos da próxima segunda-feira.

A pergunta correta que um arquiteto de software sênior deve fazer nunca é "Qual arquitetura é melhor?", mas sim "Qual o preço operacional e financeiro que a minha organização precisa e consegue pagar neste momento?".

Uma Micro-História Realista

Considere o caso de uma plataforma de gestão de estoques que tentou, ao longo de seis meses, dividir seu sistema central unificado em microsserviços sem sucesso, devido a conflitos de integridade no banco. Percebendo a perda de foco, a engenharia freou o projeto e decidiu primeiro refatorar o código interno como um Monolito Modular. Após isolarem rigidamente os módulos em Java e separarem as regras lógicas de Faturamento, uma pequena equipe de apenas quatro desenvolvedores realizou a extração real da API de faturamento como um serviço independente em três semanas.

O impacto foi imediato: o tempo de entrega (lead time) de atualizações fiscais caiu de duas semanas para apenas três dias, o custo geral de infraestrutura reduziu-se em 60% com o enxugamento de recursos e os incidentes de travamento de banco de dados por concorrência foram eliminados por completo do ambiente produtivo.

1. O Ponto de Partida Ideal: O Monolito Modular

A melhor estratégia para contornar a sobre-engenharia sem abrir mão da flexibilidade futura é começar o projeto utilizando um Monolito Modular.

Nesta abordagem, toda a aplicação roda sob um único processo executável e utiliza um único banco de dados. Contudo, no código, as dependências são organizadas de forma rigorosa em módulos independentes (usando pacotes Java bem estruturados, regras de arquitetura hexagonal ou ferramentas de validação de dependências como ArchUnit).

Isso permite que a equipe programe com a velocidade de desenvolvimento de um monolito (compilação rápida, facilidade para rodar testes na própria máquina, ausência de latência de rede), mas garanta o isolamento lógico das funcionalidades de negócio.

Erro comum: Permitir que pacotes internos de um módulo importem classes internas de outros módulos diretamente, contornando as fachadas públicas (interfaces/APIs internas) e quebrando o isolamento.

2. O Padrão da Figueira Estranguladora (Strangler Fig Pattern)

Se, ao longo do crescimento da empresa, a volumetria de um módulo específico disparar drasticamente ou exigir deploys isolados de uma equipe independente, a transição para microsserviços ocorre de forma cirúrgica utilizando o Strangler Fig Pattern (Padrão da Figueira Estranguladora).

Alguns candidatos ideais para a extração cirúrgica incluem:

• Módulo de Faturamento / Fiscal: Devido à alta frequência de mudanças regulatórias e fiscais exigindo deploys rápidos.
• Motor de Antifraude / Recomendação: Devido a picos extremos de processamento ou necessidade de processamento pesado em paralelo.
• Módulo de Catálogo / Busca: Por receber o maior volume de tráfego de leitura ociosa no dia a dia.

Em vez de reescrever todo o sistema do zero — o que geralmente resulta em fracassos comerciais catastróficos —, a equipe isola gradualmente o módulo selecionado no monolito. Cria-se uma nova aplicação independente na rede e, através de um proxy de roteamento, o tráfego é direcionado aos poucos do monolito antigo para o novo serviço. Com o tempo, a parte antiga do monolito seca e é removida de forma segura.

Erro comum: Tentar estrangular ou reescrever a aplicação inteira em um único ciclo massivo ("Big Bang"), em vez de extrair endpoints ou fluxos isolados de forma incremental.

3. O Desafio Silencioso da Decomposição do Banco de Dados

O maior erro técnico na extração de um microsserviço é esquecer de separar os dados. Se dois microsserviços distintos continuam compartilhando as mesmas tabelas no mesmo banco de dados relacional centralizado, a separação do código foi inútil. Você mantém os custos de rede das APIs, mas preserva o acoplamento físico de dados, impedindo deploys independentes.

A sincronização segura entre os bancos independentes deve ser tratada de forma assíncrona:

• Eventos de Domínio: O monolito notifica as alterações gerando mensagens para tópicos/filas assíncronas.
• Change Data Capture (CDC): Escuta as alterações físicas de dados diretamente na tabela e as propaga ao novo banco em milissegundos sem acoplamento de código.

Erro comum: Manter chaves estrangeiras físicas (foreign keys) e junções relacionais de tabelas entre bancos de dados que passarão a rodar em servidores diferentes.

4. Conclusão da Série: O Caminho Pragmático

O monolito cobra o seu preço em acoplamento de código a longo prazo se a equipe não for disciplinada com a organização dos pacotes; o microsserviço cobra o seu preço em complexidade de infraestrutura e custos em dólar desde o primeiro dia de vida do sistema.

Para a esmagadora maioria das empresas de médio porte, investir na organização interna do código (monolitos modulares) trará muito mais retorno sobre o investimento do que fragmentar a infraestrutura de servidores de forma prematura. Engenharia sênior envolve resolver problemas com o menor número possível de partes móveis.

Conclusão da Série

A modularidade é o investimento sustentável em engenharia; a extração é o dividendo pago pela maturidade do negócio. A arquitetura correta é aquela que otimiza o custo e a produtividade da próxima segunda-feira.

"A modularidade é o investimento; a extração é o dividendo. Não existe microsserviço saudável sem um monolito modular bem estruturado por baixo."

Agradecemos a leitura ao longo desta minissérie de reflexões e cálculos arquiteturais.

— Fim da Série. Volte ao Índice da Série para rever os episódios ou acesse a página inicial do blog.

Tags de compartilhamento:
#ModularMonolith #SoftwareDesign #Microservices #TechArchitecture