Microserviços vs Monólitos: O Custo da Liberdade

Se você ler os blogs de tecnologia, parece que o monólito morreu e os microserviços são a única opção. Mas, na vida real, muitos microserviços são apenas “monólitos distribuídos” que trouxeram o dobro da dor e metade do ganho. Qual arquitetura você deve escolher para o seu próximo projeto?

A Lei de Conway

“Organizações que desenham sistemas estão limitadas a produzir designs que são cópias das estruturas de comunicação dessas organizações”. Se você tem 3 times pequenos, talvez precise de 3 microserviços. Se você tem 1 time de 5 pessoas, um microserviço para cada um vai ser um caos.

1. O Monólito (Simplicidade e Rapidez)

Tudo está em um único deploy, uma única base de código e uma única transação de banco de dados.

• Prós: Fácil de testar, fácil de fazer deploy, sem latência de rede entre componentes.
• Contras: Difícil de escalar partes específicas, tempo de compilação alto, “medo” de mexer em código legado que afeta tudo.

2. Microserviços (Escala e Agilidade de Time)

Cada funcionalidade é um serviço independente, com seu próprio banco e deploy.

• Prós: Cada time escolhe sua stack, escala independente, falhas isoladas (se bem feito).
• Contras: Complexidade de rede, transações distribuídas (Saga), observabilidade difícil, custo de infraestrutura alto.

O “Doce Balanço”: O Monólito Modular

Antes de pular para microserviços, considere o Monólito Modular. Divida seu código em módulos bem definidos (usando Maven/Gradle modules ou pacotes rigorosos) que não se conhecem. Quando um módulo precisar escalar muito mais que os outros, aí sim você o extrai para um microserviço.

Quando migrar para Microserviços?

1. Escala de Times: Quando os desenvolvedores estão “trombando” um no outro no mesmo código.
2. Requisitos Técnicos Diferentes: Um módulo precisa de Python para IA e o resto é Java.
3. Escala de Recursos: Um módulo consome 90% da CPU e você quer escalá-lo sem pagar por 10 cópias do sistema inteiro.

O Princípio da Extração Justificada

Nunca comece um projeto com microserviços se você pode começar com um monólito modular. A regra de ouro é: extraia apenas quando a dor da coordenação ou a necessidade de escala técnica superar a dor da complexidade de rede. Se você não consegue organizar seus pacotes dentro de um único projeto, dificilmente conseguirá organizar centenas de serviços espalhados pela infraestrutura.