A Falácia da Escalabilidade Horizontal em Microserviços

A Dor Real: O Mito do ‘É Só Subir Mais Réplicas’

Quem já operou um cluster de verdade sabe: **microserviços não escalam horizontalmente só porque o PowerPoint diz**. A maioria dos gargalos não está no código — está nos limites físicos dos sistemas distribuídos: latência, coordenação, concorrência, filas mal projetadas e bancos estrangulados.

O hype vendia independência total, mas o que chega na prática é **acoplamento distribuído**. A cada novo serviço, nasce uma nova dependência oculta. A cada instância extra, nasce um novo gargalo em outro ponto do ecossistema.

Resultado: times criando patches emergenciais, dívidas técnicas crescendo e squads jurando que “faltou subir mais pods”.

O Caminho Pragmático: Escale Fluxos, Não Containers

Escalabilidade real não vem de replicar serviços, mas de **controlar a topologia de comunicação**. E isso significa três armas simples e pragmáticas:

• Assincronia bem pensada (fila + evento + idempotência).
• Limite explícito de throughput por domínio.
• Infra que não mente: observabilidade que mostra onde dói.

Microserviço que depende de request síncrono ponto a ponto jamais terá escalabilidade horizontal. No máximo, terá uma promessa motivacional.

Implementação de Sênior: Um Fluxo Assíncrono que Escala de Verdade

A seguir, um exemplo usando uma pipeline assíncrona baseada em eventos. Nada de gourmetização: só o essencial para escalar onde importa.

import { Kafka } from "kafkajs";

// Producer: serviço de checkout publica evento
const kafka = new Kafka({ clientId: "checkout", brokers: ["kafka:9092"] });
const producer = kafka.producer();

async function publishOrderEvent(order) {
  await producer.connect();
  await producer.send({
    topic: "order.created",
    messages: [{ value: JSON.stringify(order) }]
  });
}

// Consumer: serviço de pagamento processa no próprio ritmo
const consumer = kafka.consumer({ groupId: "payment" });

async function run() {
  await consumer.connect();
  await consumer.subscribe({ topic: "order.created" });

  await consumer.run({
    eachMessage: async ({ message }) => {
      const order = JSON.parse(message.value.toString());
      // processamento idempotente
      processPayment(order);
    }
  });
}

run().catch(console.error);

Esse fluxo:

• remove gargalos síncronos
• permite múltiplos consumidores escalarem sem se atropelar
• não derruba o sistema quando um serviço fica lento

Ou seja: **escalabilidade horizontal real surge quando cada serviço controla o ritmo e desacopla o tempo**.

O Custo da Escolha: A Verdade Que Ninguém Conta

Arquiteturas assíncronas escalam, mas cobram seu preço:

• Depuração mais complexa.
• Garantia de ordem é responsabilidade da arquitetura (não do broker).
• Idempotência deixa de ser luxo e vira obrigação.

Porém, fugir disso é escolher viver para sempre dopado por falsas promessas de replicação infinita.

Direto das Trincheiras

• Se dois microserviços precisam conversar síncronamente para cada requisição, eles não são dois microserviços — são um monólito distribuído.
• Antes de criar um novo serviço, pergunte: “ele escala diferente dos outros?” — se a resposta for não, você só criou complexidade.
• Autoscaling não resolve gargalo de banco. Nunca. Escale a carga, não o desespero.

Fontes

Arquitetura de soluções e software distribuído, DevSecOps e …, Python não escala, Java é melhor e IA vai revolucionar tudo., Is Choosing JS for Backend Development a Good Choice? – Reddit, Comunicação Assíncrona em Microserviços: O que poucos te contam?, Microservices: o que são e para o que servem?, 30.000 deploys diários: desvendando os segredos do Mercado Livre

Obrigado por acompanhar essa reflexão até o fim!

Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descascamos outros hypes da nossa área.

Valeu e até a próxima! 😉