Microsserviços vs monólito: critérios objetivos para escolher a arquitetura

A discussão monólito versus microsserviços costuma ser apresentada como evolução linear: primeiro o monólito, depois a "arquitetura madura" de serviços distribuídos. A realidade de produção é menos romântica. Microsserviços trocam complexidade de código por complexidade operacional — e essa troca só compensa em contextos específicos. Este artigo apresenta os trade-offs mensuráveis e um critério de decisão baseado em restrições reais.

Definições sem marketing

Monólito é uma aplicação implantada como uma única unidade: um processo (ou um conjunto de réplicas do mesmo processo) com uma base de código e, normalmente, um banco de dados. Monólito modular é a mesma unidade de deploy, mas com fronteiras internas explícitas entre módulos de domínio, impedindo acoplamento indevido. Microsserviços são processos independentes, cada um com deploy, escala e, idealmente, dados próprios, comunicando-se por rede.

Comparação objetiva

O custo oculto da distribuição

Cada chamada que sai do processo vira uma chamada de rede. Isso introduz latência adicional (típico de 0,5 a 5 ms dentro de uma mesma região de nuvem, contra nanossegundos em memória), falhas parciais e a necessidade de tratar timeouts. O código abaixo ilustra o tratamento mínimo que uma chamada entre serviços exige — código que simplesmente não existe em um monólito:

async function buscarPedido(id: string, tentativas = 3): Promise<Pedido> {
  for (let i = 0; i < tentativas; i++) {
    const controller = new AbortController();
    const timeout = setTimeout(() => controller.abort(), 2000);
    try {
      const res = await fetch(`https://servico-pedidos/internal/pedidos/${id}`, {
        signal: controller.signal,
        headers: { "x-request-id": crypto.randomUUID() },
      });
      if (res.status >= 500) throw new Error(`upstream ${res.status}`);
      if (!res.ok) throw new Error(`erro definitivo ${res.status}`); // não retenta 4xx
      return (await res.json()) as Pedido;
    } catch (err) {
      if (i === tentativas - 1) throw err;
      await new Promise((r) => setTimeout(r, 100 * 2 ** i)); // backoff exponencial
    } finally {
      clearTimeout(timeout);
    }
  }
  throw new Error("inalcançável");
}

Multiplique esse padrão por dezenas de integrações e some tracing distribuído, contratos versionados, filas para comunicação assíncrona e estratégias de consistência como sagas. O catálogo de padrões em microservices.io lista dezenas deles — cada um é um problema que o monólito não tem.

Quando microsserviços realmente compensam

• Times grandes e independentes: quando 5+ equipes precisam fazer deploy sem se bloquear, a fronteira de serviço alinha-se à fronteira organizacional (Lei de Conway).
• Requisitos de escala muito díspares: um endpoint de processamento de imagem consumindo 100x mais CPU que o resto do sistema justifica escala isolada.
• Requisitos de disponibilidade distintos: um módulo crítico (ex.: checkout) pode precisar de isolamento de falhas que o restante não justifica.
• Deploys frequentes e independentes: se o negócio exige releases diários por time sem janela de coordenação.

Quando o monólito (modular) é a escolha certa

Para a maioria dos produtos em estágio inicial e médio, o monólito modular entrega quase todos os benefícios organizacionais sem o custo operacional. A receita prática: um repositório, módulos por domínio com APIs internas explícitas, proibição de import cruzado fora da API do módulo, e um schema por domínio no banco. Se um dia um módulo precisar virar serviço, a fronteira já existe.

src/
  modules/
    catalogo/        # só expõe index.ts (API pública do módulo)
      index.ts       # export { listarProdutos, obterProduto }
      internal/      # repositórios, entidades — proibido importar de fora
    pedidos/
      index.ts       # importa de "modules/catalogo", nunca de internal/
      internal/
    pagamentos/
      index.ts
      internal/

Critério de decisão em 4 perguntas

1. Quantos times independentes farão deploy neste sistema? Se a resposta é 1 ou 2, monólito modular.
2. Existe um componente com perfil de carga 10x diferente do resto? Se não, monólito.
3. O time opera hoje com maturidade em observabilidade, CI/CD e infra como código? Se não, microsserviços vão amplificar o problema, não resolver.
4. O domínio é bem compreendido o suficiente para desenhar fronteiras estáveis? Fronteiras erradas em serviços custam 10x mais para corrigir do que em módulos.

Conclusão

Arquitetura é gestão de trade-offs, não busca por sofisticação. O monólito modular é o ponto de partida correto para a maioria dos sistemas; microsserviços são uma resposta organizacional e de escala, não um selo de qualidade. Empresas como a Amazon documentaram publicamente o caminho inverso — consolidar serviços de volta em processos únicos quando a distribuição não se pagava. Decida com métricas de time e de carga, não com tendência.

Perguntas frequentes

Fontes consultadas

• microservices.io — catálogo de padrões (Chris Richardson)
• Martin Fowler — Monolith First
• Amazon Prime Video — consolidação de serviços (estudo de caso)