O Imposto Silencioso dos Microsserviços: Quando os Monólitos Escalam Melhor

A armadilha da arquitetura guiada pelo currículo

Existe um patógeno perigoso a espalhar-se pelos departamentos de engenharia. Geralmente começa quando um Lead Engineer recém-contratado, ansioso por deixar a sua marca, declara que a aplicação existente não tem qualquer hipótese de escalar porque é um “monólito legado”. A cura proposta é sempre a mesma: uma reescrita de vários anos para microsserviços orquestrados por Kubernetes, a comunicar via event buses assíncronos, suportados por bases de dados independentes.

O cenário é comum: uma startup B2B em rápido crescimento com 18 engenheiros e um monólito Ruby on Rails lindamente simples a processar 5.000 pedidos por minuto com latência P99 de 120ms. Não é perfeito, mas é altamente rentável. Depois, alguém lê um artigo sobre como a Netflix escala a sua infraestrutura. Dois anos depois, a mesma equipa de 18 engenheiros mantém agora 24 microsserviços distintos.

Os resultados foram catastróficos. A velocidade de lançamento de novas funcionalidades paralisou completamente. O que antes era um simples JOIN em SQL para obter o histórico de transações de um utilizador, era agora uma saga de transações distribuídas que abrangia três equipas, exigindo padrões de resiliência de rede, lógica de repetição (retries) e tratamento de consistência eventual. O sistema não ficou mais rápido; ficou infinitamente mais difícil de depurar. Um único pedido que falhasse exigia analisar rastreios (traces) em cinco ecrãs diferentes do Datadog.

Bem-vindo ao imposto silencioso dos microsserviços. É o custo de adotar soluções à escala da Google para problemas que poderiam ter sido resolvidos com uma instância de base de dados maior e uma indexação adequada.

O que os microsserviços realmente resolvem

Para que fique claro: os microsserviços são um padrão arquitetural brilhante. Mas é preciso compreender que problema eles foram realmente concebidos para resolver. Os microsserviços resolvem problemas de escala organizacional, não problemas computacionais.

Se tens 500 engenheiros a submeter código para um único repositório, o overhead de coordenação torna-se um gargalo. Os deploys demoram horas porque os testes de integração entram em conflito. As equipas pisam os calos umas das outras a modificar a lógica central de domínio. Neste cenário, dividir o monólito em serviços independentes permite que equipas isoladas lancem funcionalidades ao seu próprio ritmo, sem quebrar o resto do sistema. É a Lei de Conway codificada em infraestrutura.

Contudo, se és uma empresa SaaS B2B com 15 engenheiros, tu não tens um problema de escala organizacional. Tens um problema de adequação do produto ao mercado (product-market fit). Dividir a tua aplicação em 12 serviços distintos significa que a tua pequena equipa tem agora de gerir logging distribuído, latência de rede, versionamento de APIs entre serviços e pipelines complexas de CI/CD. Trocaste um desafio de engenharia simples e contido pelas complexidades massivas da engenharia de sistemas distribuídos.

O custo de latência da fronteira de rede

O aspeto mais ignorado dos microsserviços é a realidade física da rede. Num monólito, chamar uma função noutro domínio demora nanossegundos. É uma instrução de CPU. Numa arquitetura de microsserviços, essa mesma chamada de função envolve serialização (geralmente para JSON), um handshake TCP, negociação TLS, trânsito na rede, desserialização e roteamento.

Considera um fluxo de checkout normal de comércio eletrónico. Num monólito, obter os itens do carrinho, verificar o inventário, aplicar descontos e criar uma encomenda pode ser envolvido numa única transação de base de dados.

BEGIN;
  -- Bloquear a linha de inventário
  SELECT quantidade FROM inventario WHERE produto_id = 42 FOR UPDATE;
  
  -- Deduzir inventário
  UPDATE inventario SET quantidade = quantidade - 1 WHERE produto_id = 42;
  
  -- Criar encomenda
  INSERT INTO encomendas (utilizador_id, total) VALUES (99, 150.00);
COMMIT;

Se qualquer passo falhar, a transação faz um rollback. Isto é matematicamente garantido pelas propriedades ACID do PostgreSQL.

Agora, imagina isto numa arquitetura de microsserviços. Tens um InventoryService, um OrderService e um DiscountService. Não podes usar uma transação simples de base de dados. Tens de implementar o padrão Saga. Se o OrderService falhar depois do InventoryService já ter deduzido o item, tens de enviar um evento compensatório para restaurar o inventário.

// Uma lógica orquestradora de saga simplificada
async function processarCheckout(carrinho) {
  try {
    // 1. Reservar Inventário (Chamada de Rede)
    await axios.post('http://inventory-svc/reservar', { itens: carrinho.itens });
    
    try {
      // 2. Aplicar Descontos (Chamada de Rede)
      const desconto = await axios.post('http://discount-svc/calcular', { user: carrinho.userId });
      
      try {
        // 3. Criar Encomenda (Chamada de Rede)
        return await axios.post('http://order-svc/criar', { carrinho, desconto });
      } catch (orderError) {
        // Transação compensatória para o desconto
        await axios.post('http://discount-svc/reverter', { user: carrinho.userId });
        throw orderError;
      }
    } catch (discountError) {
      // Transação compensatória para o inventário
      await axios.post('http://inventory-svc/libertar', { itens: carrinho.itens });
      throw discountError;
    }
  } catch (error) {
    logger.error("Falha na Saga de Checkout", error);
    throw new CheckoutException("Não foi possível processar a encomenda");
  }
}

O que outrora eram três linhas de SQL é agora uma dança frágil na rede. Se a rede perder um pacote durante a transação compensatória, o estado do sistema fica permanentemente corrompido, e depurar o problema exige analisar traces em cinco dashboards diferentes do Jaeger ou Datadog. Este é o imposto silencioso. Está a ser pago todos os dias em ciclos de engenharia que deviam estar a construir funcionalidades que os clientes realmente querem.

O Monólito Majestoso em 2026

A indústria está lentamente a acordar para esta realidade. O conceito de “Monolith First” está a ganhar tração novamente. Na moderna arquitetura cloud, um monólito bem estruturado e implantado em infraestrutura escalável é incrivelmente poderoso.

Um monólito não significa “código esparguete”. Podes ter limites estritamente impostos, domínios modulares e uma separação limpa de responsabilidades dentro de uma única base de código. Na verdade, fazer isto dentro de um monólito é drasticamente mais fácil do que fazê-lo através de limites de rede. Se um limite estiver errado num monólito, refatoras um namespace. Se um limite estiver errado numa arquitetura de microsserviços, estás a reescrever APIs, a migrar bases de dados e a coordenar deploys entre várias equipas.

Além disso, o hardware que temos hoje à nossa disposição é estonteante. Uma instância AWS r7g.16xlarge moderna dá-te 64 cores ARM e 512GB de RAM. Uma base de dados PostgreSQL devidamente otimizada em armazenamento NVMe consegue processar centenas de milhares de transações por segundo. A menos que estejas a transmitir vídeo globalmente ou a processar dados de high-frequency trading, a escalabilidade vertical de um monólito bem escrito vai levar-te muito mais longe do que imaginas.

Quando deves realmente fragmentar o monólito

O consenso de engenharia, e o padrão que o x078 vê validado em dezenas de auditorias de arquitetura por ano, está a convergir: começa com um monólito. Constrói-o de forma modular com fronteiras de domínio limpas dentro de uma única unidade deployável. Quando um componente específico exigir genuinamente escalabilidade independente (talvez uma fila de processamento de imagens ou um serviço pesado de geração de PDFs) recorta essa peça específica para um serviço separado.

Não comeces com microsserviços. Extrai-os apenas quando a dor de manter o monólito for manifestamente superior ao imenso imposto operacional de um sistema distribuído. A arquitetura deve ser orientada por restrições de negócio, não pelo que fica bonito num slide de conferência. Constrói um monólito bem estruturado. Otimiza as queries de base de dados. Usa cache de forma agressiva. O resultado vai surpreender.