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! 😉
