Microsserviços ou monólito: critérios além da escalabilidade

Microsserviços não são uma versão mais madura do monólito. São uma troca: isolamento de deploy, carga e responsabilidade em troca de chamadas de rede, consistência distribuída, observabilidade e coordenação operacional.

Para muitos sistemas empresariais, um monólito modular é o ponto de partida com melhor relação entre custo e capacidade de evolução.

O que é um monólito modular

É uma aplicação com um processo de deploy, organizada por domínios e contratos internos. Módulos não acessam dados uns dos outros de qualquer forma; expõem operações claras e preservam limites que podem ser testados.

Um único deploy reduz o número de falhas parciais e simplifica transações. Isso não impede escala horizontal nem processamento em segundo plano.

O que muda ao distribuir

Uma chamada local vira rede. Uma transação pode virar eventos e compensações. Logs de um processo deixam de contar toda a história. Cada serviço precisa de deploy, configuração, credenciais, métricas e resposta a incidentes.

Esses custos são justificáveis quando compram um benefício concreto:

• uma carga precisa escalar de forma muito diferente das demais;
• existe um limite de segurança que exige isolamento;
• equipes autônomas respondem por domínios estáveis;
• um componente tem dependências ou runtime próprios;
• disponibilidade e implantação precisam ser independentes.

Quando permanecer no monólito

Prefira manter um deploy quando o domínio ainda muda rápido, a equipe é pequena, o volume é atendido com dimensionamento simples ou a separação exigiria duplicar dados sem benefício claro.

Antes de dividir, tente:

1. medir consultas e workloads que realmente limitam o sistema;
2. extrair processamento pesado para workers;
3. criar limites de módulo e remover acessos cruzados;
4. melhorar cache e banco de dados com evidência;
5. automatizar deploy, backup e observabilidade.

Muitas vezes, o problema atribuído ao monólito é acoplamento sem limites, consultas ruins ou falta de capacidade operacional.

Filas não transformam tudo em microsserviço

Um monólito pode publicar trabalhos para workers separados e continuar sendo uma única unidade de domínio. Essa separação ajuda em tarefas demoradas, retentativas e picos sem exigir que cada módulo tenha banco e API próprios.

Perguntas para uma extração responsável

• O domínio tem dono e fronteira entendidos?
• Que dado pertence ao serviço e como outros contextos o consultarão?
• O fluxo aceita consistência eventual?
• Como duplicidade, ordenação e reprocessamento serão tratados?
• Há correlação de logs, métricas e alertas entre componentes?
• Quem mantém o serviço fora do horário de desenvolvimento?
• É possível migrar gradualmente e voltar se a hipótese estiver errada?

Exemplo de decisão pragmática

Um marketplace de infraestrutura pode manter regras comerciais em uma API e isolar um worker de provisionamento que acessa equipamentos de rede. A divisão não existe para aumentar a contagem de serviços: ela reduz acesso desnecessário e concentra uma responsabilidade operacional sensível.

Esse tipo de limite é mais defensável do que separar “usuários”, “produtos” e “pedidos” apenas porque são substantivos diferentes.

Conclusão

Comece com o sistema mais simples que preserve limites claros. Extraia serviços quando houver uma razão mensurável de carga, segurança, tecnologia ou organização. Se a justificativa for apenas “escalar no futuro”, registre a hipótese e invista primeiro em um monólito que possa ser observado e mudado.