Monolito vs Microservices: quando usar cada um

Introdução: o falso dilema

Poucas discussões em engenharia de software geram tanto debate quanto monolito vs microsserviços. De um lado, times que migraram para microsserviços cedo demais e hoje lidam com complexidade operacional desproporcional ao problema que resolvem. Do outro, times que insistem em um monolito gigante e sofrem para escalar times e sistemas juntos.

A verdade é que essa não é uma escolha binária nem permanente. É uma decisão de trade-off contextual, que depende do tamanho do time, da maturidade operacional, da criticidade do negócio e — principalmente — do estágio atual da empresa.

O que é arquitetura monolítica

Um monolito é uma aplicação construída e implantada como uma única unidade. Todo o código — autenticação, catálogo, pagamento, notificações — roda no mesmo processo, compartilha o mesmo banco de dados e é implantado de uma só vez.

O que são microsserviços

Microsserviços dividem o sistema em serviços independentes, cada um com seu próprio processo, banco de dados e ciclo de deploy, comunicando-se via rede (HTTP, gRPC, mensageria).

O meio-termo: monolito modular

Antes de pular direto para microsserviços, vale conhecer o monolito modular: uma única aplicação implantada como unidade, mas com fronteiras internas bem definidas entre módulos — cada um com sua própria responsabilidade, interfaces claras e, idealmente, seu próprio schema dentro do mesmo banco.

Se amanhã for necessário extrair um módulo como serviço independente, um monolito modular já desacoplado facilita — e muito — essa transição.

Quando usar monolito

Sinais de que chegou a hora de extrair serviços

Os custos ocultos dos microsserviços

Microsserviços são frequentemente vendidos como solução universal, mas carregam custos que raramente aparecem nos slides de arquitetura:

Exemplo prático: do monolito ao serviço extraído

No monolito, o módulo de pedidos chama diretamente a lógica de pagamento, no mesmo processo:

// orders/service.js
const paymentService = require('../payments/service');

async function createOrder(orderData) {
  const order = await Order.create(orderData);
  const payment = await paymentService.charge(order.total, order.customerId);
  order.paymentStatus = payment.status;
  await order.save();
  return order;
}

Ao extrair pagamentos como microsserviço, a chamada passa a ser uma requisição de rede, com tratamento explícito de falhas e timeouts:

// orders-service/service.js
const axios = require('axios');

async function createOrder(orderData) {
  const order = await Order.create(orderData);

  try {
    const { data: payment } = await axios.post(
      'https://payments.internal.wdseven.com/v1/charge',
      { amount: order.total, customerId: order.customerId },
      { timeout: 3000 }
    );
    order.paymentStatus = payment.status;
  } catch (err) {
    order.paymentStatus = 'pending_retry';
    await enqueueRetry('payment-charge', order.id);
  }

  await order.save();
  return order;
}

Note que a extração não é apenas "mover código": exige lidar com timeout, retry e estados intermediários que não existiam quando tudo rodava no mesmo processo. Esse é o custo invisível de desacoplar.

Comparação direta

Como migrar sem reescrever tudo

A migração mais segura de monolito para microsserviços é incremental, usando o padrão Strangler Fig: novas funcionalidades (ou módulos extraídos) nascem como serviços independentes, enquanto o monolito continua operando até ser gradualmente esvaziado.

Checklist de decisão

Conclusão

A escolha entre monolito e microsserviços não deve ser guiada por tendência de mercado, mas por contexto real: tamanho do time, maturidade operacional e necessidades reais de escala. Para a maioria das empresas em estágio inicial, um monolito bem modularizado é o caminho mais rápido e seguro — e deixa a porta aberta para extrair serviços quando (e se) a escala exigir.