Microsserviços vs. Monólito: como escolher a arquitetura certa?

Nos últimos anos, microsserviços viraram símbolo de "tecnologia moderna" no mercado brasileiro. Startups, PMEs e empresas tradicionais adotam a arquitetura sem questionar se ela resolve o problema que têm — e frequentemente criam problemas novos que não tinham antes.

A realidade é mais sóbria: não existe arquitetura universalmente melhor. Existe a arquitetura certa para o seu contexto. E escolher errado tem custo alto — de tempo, dinheiro e sanidade do time.

O que é um monólito (e por que não é palavrão)

Monólito é um sistema onde todos os módulos rodam no mesmo processo e são deployados juntos. O GitHub rodou como monólito por anos. O Shopify ainda é essencialmente um monólito em Rails. O Stack Overflow serve bilhões de pageviews por mês com uma arquitetura relativamente simples.

Um monólito bem estruturado — com separação clara de domínios internos, testes sólidos e abstrações bem definidas — é simples de desenvolver, testar, deployar e operar. Não tem overhead de comunicação de rede, não exige orquestração de containers e permite refatoração com muito mais facilidade.

O que são microsserviços (e qual é o custo real)

Microsserviços dividem o sistema em serviços independentes, cada um responsável por um domínio específico, comunicando-se via APIs ou mensageria assíncrona. Cada serviço tem seu próprio deploy, banco de dados e ciclo de vida.

Os benefícios são reais: deploys independentes, escalabilidade granular, isolamento de falhas, autonomia de times. Mas esses benefícios têm custo:

• Complexidade de operação exponencialmente maior: você passa a gerenciar N sistemas em vez de 1
• Latência de comunicação: chamadas de rede adicionam latência que não existe em chamadas de função locais
• Consistência eventual: transações distribuídas são muito mais complexas de implementar corretamente
• Rastreamento de bugs distribuído: um bug que cruza múltiplos serviços é muito mais difícil de diagnosticar
• Overhead de DevOps: CI/CD para 20 serviços é muito mais complexo do que para 1

Quando microsserviços fazem sentido

• Você tem múltiplos times independentes que precisam deployar sem coordenar entre si
• Partes específicas do sistema têm requisitos de escala muito diferentes (ex: módulo de processamento vs. módulo de relatórios)
• Você precisa de isolamento técnico real entre domínios (ex: compliance exige que dados financeiros rodem em ambiente separado)
• O sistema já cresceu ao ponto onde o monólito tem custo de manutenção alto e um mapa claro de divisão por domínio já existe

Quando um monólito modular é a escolha certa

• Time pequeno (menos de 10 devs) — o overhead de microsserviços supera o benefício
• Sistema em fase inicial ou com escopo ainda em definição — fronteiras de domínio mudam e serviços distribuídos são caros de refatorar
• Orçamento e time de DevOps limitados — operar microsserviços bem exige investimento significativo em infraestrutura
• Sem requisito claro de escalabilidade diferenciada entre módulos

O meio-termo: o monólito modular

A arquitetura mais subestimada hoje é o monólito modular — também chamado de "modular monolith". Você mantém o sistema em um único processo, mas com fronteiras de domínio bem definidas internamente. Cada módulo tem seus próprios modelos, serviços e lógica de negócio — sem acesso direto ao banco de dados ou código de outro módulo.

Isso permite evoluir para microsserviços quando necessário: as fronteiras já existem, basta "separar os fios". É o melhor dos dois mundos: simplicidade operacional no início, com caminho claro para distribuição quando o negócio exigir.