Em muita conversa de arquitetura, a pergunta chega pronta: “vamos de microsserviços, né?”. Como se monólito fosse o estágio atrasado e microsserviços, a versão madura do mesmo sistema.

Não é assim. São duas estratégias de distribuição, cada uma com um preço. E nenhuma delas resolve o problema que costuma estar por trás da pergunta: o sistema não tem limites claros.

Limites vêm antes da distribuição

A primeira forma de lidar com complexidade é separar responsabilidades. Módulos com linguagem própria, regras próprias e dependências explícitas. Essa separação não exige que cada módulo rode num processo diferente.

Um monólito modular é exatamente isso: um único artefato de implantação, com módulos que conversam por interfaces internas e não mexem nos dados uns dos outros. Para equipes pequenas ou produtos ainda em descoberta, essa combinação costuma preservar velocidade e clareza.

Microsserviços acrescentam autonomia de implantação e escala independente. Em troca, cobram contratos entre serviços, observabilidade distribuída, automação, tolerância a falhas e gestão de consistência. Se o sistema já não tem limites compreensíveis dentro de um processo, distribuí-lo normalmente só espalha a desordem pela rede.

O que cada um custa

Repare na linha de transações. Quando uma operação altera dados e publica um evento em serviços diferentes, uma etapa pode concluir e a outra falhar. Aí entram Outbox, consumidores idempotentes, sagas e filas de exceção. São padrões ótimos, e cada um é código e operação que o monólito não precisaria ter.

Quando separar um módulo

Uma decisão prudente costuma começar modular e adiar a distribuição. A extração de um módulo passa a ter evidência quando ele mostra, de fato, algo diferente do resto:

• muda num ritmo muito diferente dos outros módulos;
• precisa escalar de forma independente;
• exige disponibilidade maior que o conjunto;
• tem um time próprio que responde por ele em produção.

O critério é a capacidade de negócio, não o organograma nem a preferência tecnológica. Dividir o sistema em “serviço de banco”, “serviço de validação” e “serviço de tela” é distribuir camadas, não capacidades.

Um exemplo de dependência consciente

Num repositório institucional de acervos em que trabalhei (o caso está anonimizado no livro), a equipe era pequena e a solução precisava durar anos. A decisão foi manter uma plataforma de repositório consolidada como núcleo, organizar as customizações em módulos e serviços de integração controlados, e rodar tarefas demoradas, como OCR, de forma assíncrona.

Nada de microsserviços por padrão. Os limites estavam onde havia regras institucionais específicas, e a distribuição apareceu só onde havia motivo: o processamento demorado não podia travar a submissão de documentos. A complexidade não sumiu. Ela ficou concentrada onde existia diferencial.

Antes de decidir, responda

• Os módulos de hoje têm limites claros e dados com dono?
• Que parte do sistema precisa escalar, mudar ou falhar de forma independente?
• O time tem automação e observabilidade para operar vários serviços?
• Onde você aceita consistência eventual, e onde não aceita?
• A decisão está registrada com contexto, alternativas e custo? (Se não, veja como escrever um ADR.)

Para ir além

O capítulo 7 do livro Engenharia de Software: Fundamentos e Práticas trata a arquitetura como um conjunto de decisões: drivers e cenários de qualidade, trade-offs, construir ou integrar, síncrono ou assíncrono, Outbox e idempotência, e dois casos completos da minha experiência.

Veja o sumário e leia o começo do livro.