Monólito Modular vs. Microsserviços: Como Escolher sem Pagar Cedo pela Distribuição

English summary: A practical comparison of modular monoliths and microservices, with module contracts, extraction criteria, operational failure modes, cost, observability, security, incremental migration, and a decision checklist.

Published April 2026 Reading time: 18 min Keywords: monólito modular, microsserviços, arquitetura de software, DDD, observabilidade, migração incremental

Um time pequeno pode passar semanas discutindo como dividir o sistema em microsserviços e ainda não ter decidido quem é dono de um dado, de um contrato ou de um alerta. Enquanto isso, cada nova chamada de rede acrescenta um lugar para timeout, retry duplicado e incidente.

A tese deste artigo é simples: comece pela fronteira de negócio e pelo contrato; só crie uma fronteira de processo quando a independência operacional pagar o custo da distribuição. Um monólito modular não é uma desculpa para acoplamento. Microsserviços não são uma prova de maturidade. São duas formas de distribuir responsabilidades, com preços operacionais diferentes.

O que está sendo comparado

Um monólito modular é um único artefato implantável e, normalmente, um único processo, organizado em módulos que têm responsabilidades, dados e APIs internas explícitas. Os módulos podem compartilhar runtime e transações locais, mas não devem compartilhar qualquer detalhe por conveniência.

Microsserviços são componentes implantáveis e operáveis de forma independente. Cada serviço precisa ter uma capacidade de negócio coerente, um dono, um contrato de comunicação e autoridade sobre seus dados. Separar pastas, containers ou repositórios sem essa autonomia cria apenas um monólito distribuído.

O nome da arquitetura importa menos do que os invariantes. Um módulo com acesso às tabelas de outro módulo não é modular porque está em uma pasta bonita. Um serviço que precisa de cinco chamadas síncronas para responder não é independente porque tem um Deployment próprio.

Quando um workflow simples é melhor

Nem todo problema precisa de uma decisão arquitetural sofisticada. Um batch que lê dados, processa uma fila e grava um resultado pode ser um workflow simples. Uma aplicação CRUD com baixo volume pode permanecer em um monólito convencional enquanto o domínio é aprendido. O custo de introduzir fronteiras só se justifica quando existe uma mudança concreta: equipes precisam publicar separadamente, uma capacidade tem um perfil de escala muito diferente, uma falha precisa ser contida ou um requisito de isolamento é real.

Quatro falhas recorrentes antes de escolher a solução

Antes de vender uma arquitetura, procure os modos como o desenho atual falha. Eles mostram qual fronteira falta — e também se o problema é modularidade, operação ou apenas processo.

1. O Big Ball of Mud

O sintoma é um caso de uso que lê diretamente a tabela de outro domínio, instancia seu serviço interno e altera o estado de três áreas sem contrato. A mudança parece local, mas exige conhecimento de todo o sistema.

// O problema não é estar no mesmo processo.
// O problema é atravessar a fronteira sem um contrato.
export async function createOrder(input: CreateOrderInput) {
  const customer = await customerTable.findById(input.customerId);
  await paymentService.charge(customer.cardNumber, input.total);
  await inventoryTable.updateStock(input.items);
  return orderTable.insert(input);
}

O resultado é acoplamento semântico, testes que precisam montar o sistema inteiro e ownership indefinido. Extrair esse código para três serviços não corrige o acoplamento; transforma imports em chamadas de rede.

2. O monólito distribuído

Cada serviço é implantado separadamente, mas o fluxo de checkout exige uma cadeia síncrona de pedidos, clientes, preços, estoque e pagamentos. Um deploy precisa coordenar todos. Um timeout em qualquer elo bloqueia o usuário. O sistema ganhou a latência e a indisponibilidade da rede sem ganhar autonomia.

O alerta é uma frase como “não podemos atualizar este serviço sem atualizar os outros quatro”. Independência de deploy deve ser medida pelo fluxo real, não pelo número de manifests.

3. O banco compartilhado como contrato secreto

Quando vários componentes escrevem diretamente nas mesmas tabelas, o schema vira a API não versionada do sistema. Um índice, uma coluna renomeada ou uma mudança de semântica pode quebrar consumidores que ninguém conhece.

Um banco único pode ser uma decisão válida no monólito modular, desde que cada módulo tenha ownership explícito, acesso encapsulado e regras verificáveis. O problema não é a quantidade de instâncias de banco; é a autoridade sobre o dado.

4. A operação invisível

A equipe sabe que o endpoint falhou, mas não sabe em qual módulo, contrato ou dependência. Logs não carregam trace_id, eventos não têm versão, métricas não distinguem checkout de catálogo e o custo de infraestrutura é somado sem atribuição.

Sem observabilidade, um microsserviço é uma unidade de implantação que pode falhar de forma mais difícil de explicar. Observabilidade deve existir antes da extração, para que a comparação tenha uma linha de base.

O desenho mínimo de um monólito modular

O objetivo não é prever todos os futuros serviços. É tornar explícito o que pode mudar junto e o que não pode atravessar uma fronteira sem permissão.

src/
├── modules/
│   ├── orders/
│   │   ├── domain/
│   │   ├── application/
│   │   ├── infrastructure/
│   │   └── public.ts
│   ├── payments/
│   │   ├── domain/
│   │   ├── application/
│   │   └── public.ts
│   ├── inventory/
│   │   └── public.ts
│   └── customers/
│       └── public.ts
├── platform/
│   ├── database/
│   ├── events/
│   └── observability/
└── app.ts

public.ts não deve exportar entidades, repositórios ou tabelas internas. Ele expõe comandos, consultas e eventos que representam a linguagem do módulo. Uma regra arquitetural pode impedir imports de modules/payments/domain a partir de modules/orders e permitir apenas modules/payments/public.

Exemplo de contrato e adaptador

Neste exemplo, Orders depende de uma porta própria. A implementação pode chamar Payments no mesmo processo hoje e uma API amanhã, sem alterar o caso de uso. O exemplo usa um token de pagamento, não dados de cartão; autenticação, idempotência e persistência de outbox continuam sendo responsabilidades de produção.

// modules/orders/public.ts
export type OrderId = string & { readonly __brand: "OrderId" };

export type OrderCreatedV1 = {
  type: "orders.order-created";
  version: 1;
  orderId: OrderId;
  itemIds: string[];
  occurredAt: string;
};

// A porta pertence ao módulo consumidor: Orders define o que precisa.
export interface PaymentPort {
  authorize(input: {
    orderId: OrderId;
    amountInCents: number;
    paymentToken: string;
    idempotencyKey: string;
  }): Promise<{ authorizationId: string; status: "authorized" | "declined" }>;
}

export interface OrdersPublicApi {
  create(input: {
    customerId: string;
    itemIds: string[];
    paymentToken: string;
  }): Promise<{ orderId: OrderId; status: "pending" | "confirmed" }>;
}

// modules/orders/application/create-order.ts
import type { OrderId, OrdersPublicApi, PaymentPort } from "../public";

export function createOrdersApi(deps: {
  payments: PaymentPort;
  orders: { insert: (input: unknown) => Promise<{ id: string; totalInCents: number }> };
}): OrdersPublicApi {
  return {
    async create(input) {
      const order = await deps.orders.insert(input);
      const orderId = order.id as OrderId;
      const payment = await deps.payments.authorize({
        orderId,
        amountInCents: order.totalInCents,
        paymentToken: input.paymentToken,
        idempotencyKey: `order:${order.id}`,
      });

      return {
        orderId,
        status: payment.status === "authorized" ? "confirmed" : "pending",
      };
    },
  };
}

O contrato é útil apenas se houver regras para mantê-lo. Vale registrar, por módulo:

• o dono técnico e o dono de negócio;
• os comandos síncronos e os eventos assíncronos publicados;
• os dados que o módulo lê e escreve;
• o que é público, interno, versionado ou experimental;
• limites de timeout, retry, idempotência e autorização;
• testes que falham quando alguém atravessa a fronteira.

Eventos também são contratos. orders.order-created precisa de versão, identificador único, timestamp e política de evolução. Um event bus interno não elimina a necessidade de tratar duplicidade, ordenação e falha de handler; apenas torna esses problemas locais e mais baratos de testar.

O que realmente muda ao adotar microsserviços

Microsserviços não são “módulos melhores”. São uma mudança de unidade de falha, deploy, identidade, dados e operação. A orientação da Microsoft destaca exatamente os custos que aparecem quando a decomposição é tratada só como divisão de código: consistência de dados, versionamento, latência, testes de dependências, logging correlacionado e necessidade de maturidade DevOps.

A vantagem de escala independente é real quando a carga, o perfil de recursos ou a disponibilidade de um domínio são significativamente diferentes. Se Orders e Inventory sempre escalam juntos, separá-los adiciona uma fronteira sem comprar capacidade útil.

Falhas operacionais que a rede introduz

Uma função local falha de um jeito. Uma chamada remota pode expirar, ser executada e perder a resposta, ser repetida, retornar uma versão incompatível ou encontrar um serviço parcialmente saudável.

Retries não são uma política de disponibilidade por si só. Eles aumentam carga justamente quando a dependência está sob pressão. Toda política precisa de limite, jitter, idempotência e uma resposta clara para o caso em que o resultado é desconhecido.

Custo e observabilidade: compare o sistema inteiro

O custo de um serviço não é apenas a CPU do container. Uma conta útil precisa considerar:

custo_total = compute
            + banco_e_storage
            + rede_e_egress
            + pipelines_e_ambientes
            + plataforma_e_on_call
            + custo_de_migração

O monólito modular costuma ter custo fixo menor: menos imagens, dashboards, certificados, filas, regras de rede e ambientes para manter. Seu custo oculto aparece quando um módulo pesado força a escala da aplicação inteira ou quando um deploy amplo aumenta a janela de risco.

Microsserviços podem reduzir custo variável ao escalar um consumidor específico, mas acrescentam custo fixo e cognitivo. Se a equipe não consegue atribuir custo por serviço, ambiente e operação, “escala independente” é uma hipótese, não uma economia comprovada.

O mínimo observável nos dois modelos

• logs estruturados com request_id, trace_id, módulo, operação, versão e resultado;
• métricas de taxa, erros, latência, saturação e fila, separadas por capacidade de negócio;
• traces para o fluxo crítico, incluindo chamadas entre módulos ou serviços;
• eventos com event_id, correlation_id, versão, produtor, consumidor e timestamp;
• dashboards de jornada: checkout iniciado, pagamento autorizado, estoque reservado e pedido confirmado;
• custo de infraestrutura e de chamadas externas ligado ao domínio que gerou a carga;
• alertas com dono, severidade, runbook e condição de recuperação.

No monólito, tracear módulos internos evita que “um processo saudável” esconda um módulo degradado. Em microsserviços, o trace precisa atravessar a rede e sobreviver a retries. OpenTelemetry fornece o modelo de traces, spans e contexto; a escolha do backend não substitui a definição de quais jornadas importam.

Segurança não vem do número de processos

Um monólito modular pode ter isolamento de autorização, ownership de dados e limites de segredo. Um microsserviço pode compartilhar uma credencial administrativa, aceitar tráfego de qualquer origem e expor PII demais. O processo de deploy não é um boundary de segurança automaticamente.

Use o princípio do menor privilégio, autenticação entre workloads e validação de entrada em toda fronteira. A OWASP Microservices Security Cheat Sheet é uma referência prática para threat modeling, identidade, secrets, comunicação e logging. Se o requisito é isolamento regulatório ou de dados, escreva qual isolamento é exigido — processo, conta, região, chave, banco ou operador — antes de concluir que microsserviços resolvem o problema.

Critérios para extrair um módulo

O tamanho do diretório, a quantidade de classes e o desejo de “ter escala” são sinais fracos. Extraia quando a fronteira já for compreendida e a independência resolver um custo mensurável.

Um candidato forte costuma satisfazer a maior parte destes critérios:

1. Ownership claro: uma equipe responde por código, dados, SLO e incidentes.
2. Vocabulário estável: o domínio tem regras próprias e não é apenas um CRUD de outra área.
3. Dados protegíveis: existe um plano para deixar de escrever nas tabelas de outros módulos.
4. Contrato observável: entradas, saídas, erros, eventos, autorização e compatibilidade têm testes.
5. Baixa chatice síncrona: o serviço não precisa chamar uma sequência de dependências para cada request.
6. Perfil diferente: carga, CPU, memória, latência, disponibilidade ou ciclo de release justificam escala própria.
7. Falha aceitável: o produto sabe o que fazer quando o serviço está indisponível ou o resultado é desconhecido.
8. Operação pronta: métricas, logs, traces, alertas, runbook, deploy gradual e rollback existem.
9. Segurança explícita: identidade, autorização, secrets, PII e egress têm donos e controles.

Extração é uma decisão de produto e operação tanto quanto de código. Se o único argumento é “o módulo tem muitas linhas”, modularize dentro do monólito e meça antes.

Tabela de decisão

Use esta tabela como uma conversa com evidências, não como uma pontuação automática. Marque a coluna que descreve o problema real e registre um link para métrica, incidente, contrato ou requisito.

Regra de desempate: escolha o desenho que preserva mais opções com o menor custo de reversão. Um monólito modular com contratos permite extrair depois. Um conjunto de serviços mal delimitados acumula decisões distribuídas difíceis de desfazer.

Migração incremental: módulo primeiro, processo depois

Migração segura não é copiar uma pasta para outro repositório. É substituir uma implementação atrás de um contrato, mantendo uma única autoridade para cada efeito.

Passo 1: medir e delimitar

Mapeie chamadas, tabelas, eventos, usuários, SLOs, custos e incidentes do módulo. Crie testes de contrato e uma regra que impeça novas dependências internas. A Spring Modulith é um exemplo de tooling que valida a estrutura, documenta módulos e observa interações em aplicações Spring; o princípio vale em qualquer stack.

Passo 2: encapsular o dado

Escolha o dono de cada tabela ou agregado. Troque acesso direto por uma API interna. Se outros módulos precisam de informação, publique uma consulta ou uma projeção; não entregue um repositório compartilhado como atalho permanente.

Passo 3: estabilizar o contrato

Use compatibilidade expand-and-contract: adicione o novo campo, migre consumidores, observe, só então remova o antigo. Para eventos, aceite duplicidade e reprocessamento. Para efeitos externos, use idempotência. Para publicar junto com uma mudança de banco, considere outbox transacional.

Passo 4: trocar o adaptador

O caso de uso continua dependendo da porta. Em produção, um flag de roteamento pode enviar uma parcela controlada para a implementação remota, mas não deve criar dois escritores concorrentes do mesmo estado.

const payments: PaymentPort = flags.remotePayments
  ? new HttpPaymentAdapter({ baseUrl: env.PAYMENTS_URL, auth: serviceIdentity })
  : new LocalPaymentAdapter({ paymentGateway, outbox });

const orders = createOrdersApi({ payments, orders: orderRepository });

O adaptador HTTP precisa de timeout, deadline, autenticação, validação de resposta, retry limitado e uma estratégia para “resultado desconhecido”. fetch() sozinho não é um desenho de resiliência.

Passo 5: extrair, cortar e apagar

Suba o novo serviço com o contrato já exercitado. Faça canary ou roteamento gradual, compare erros, latência, custo e resultados de negócio. Quando o caminho remoto for a autoridade, remova a implementação local, as permissões antigas e as métricas que não têm mais dono.

Esse padrão é compatível com o Strangler Fig da AWS: substituir partes do monólito progressivamente, com uma interface que reduz risco e interrupção. O padrão não autoriza manter duas fontes de verdade indefinidamente.

O harness operacional da arquitetura

Toda escolha precisa de um harness: o conjunto de contexto, ferramentas, permissões, ambiente, verificação e observabilidade que torna o sistema operável. O monólito modular tem um harness menor; microsserviços exigem que ele seja distribuído e versionado.

O OpenTelemetry pode padronizar sinais, mas não decide quais eventos são relevantes. A equipe precisa nomear o fluxo crítico, o dono do alerta e a ação de recuperação. Sem isso, adicionar um collector apenas produz mais dados.

Checklist antes de decidir

Para permanecer em um monólito modular

• Cada módulo tem dono, API pública e lista de dependências permitidas.
• Acesso às tabelas de outros módulos é bloqueado ou visivelmente justificado.
• Comandos e eventos têm contratos, versão, idempotência e testes.
• Logs e métricas carregam módulo, operação, versão e correlação.
• O deploy amplo tem testes, health checks, rollback e janela de mudança claros.
• Existe uma medição de qual módulo realmente precisa de escala diferente.

Para extrair um serviço

• O motivo é mensurável: escala, release, disponibilidade, ownership ou isolamento.
• A equipe tem SLO, on-call, runbook e orçamento para operar o serviço.
• O serviço pode controlar seus dados sem escrita cruzada permanente.
• O contrato é backward-compatible e testado com consumidores.
• Timeouts, retries, idempotência, circuit breaker e limites de concorrência foram desenhados.
• Há trace distribuído, métricas de dependência, alertas e atribuição de custo.
• Identidade, autorização, secrets, PII e egress foram revisados.
• O cutover tem canary, rollback e um plano para resultado desconhecido.
• O caminho antigo será removido, com data e responsável definidos.

Conclusão

Monólito modular e microsserviços são pontos diferentes no espaço de fronteiras. O primeiro concentra o runtime para reduzir complexidade de rede; o segundo paga complexidade distribuída para comprar independência operacional onde ela tem valor.

A decisão madura não pergunta “qual arquitetura escala mais?”. Pergunta: qual fronteira de negócio já é compreendida, qual custo ela elimina e qual operação a equipe consegue provar que sustenta?

Comece modular quando o domínio ainda está sendo descoberto. Faça contratos e ownership valerem dentro do processo. Extraia um módulo quando sua escala, ciclo de release, disponibilidade, segurança ou responsabilidade justificarem um processo próprio. E trate cada extração como uma mudança reversível, observável e com uma única fonte de verdade.

Fontes primárias

1. Martin Fowler, MonolithFirst.
2. Microsoft Azure Architecture Center, Microservices architecture style.
3. Microsoft Azure Architecture Center, Design patterns for microservices.
4. AWS Prescriptive Guidance, Strangler Fig pattern.
5. Spring, Spring Modulith fundamentals.
6. OpenTelemetry, Traces e Signals.
7. OWASP, Microservices Security Cheat Sheet.