Kubernetes Não é Milagre: A Verdade Crua Sobre Escalabilidade Que Ninguém Te Conta

A Dor Real: Onde a Escalabilidade Vira Ilusão

A maioria dos times corre para o Kubernetes como se fosse um passe de mágica para desempenho. **Mas não existe escalabilidade grátis.** Existe CPU, memória e conta de nuvem. E o pior: existe cluster mal dimensionado tentando resolver gargalos que não são de infraestrutura, e sim de modelagem de domínio ruim.

É aqui que muitos devs se queimam: o problema nunca foi falta de pods. Foi falta de entendimento do fluxo de negócio, filas mal configuradas, APIs acopladas e serviços que viraram monolitos distribuídos sem ninguém admitir.

Solução Pragmática: Escale o que importa, não o cluster inteiro

Escalar no Kubernetes só funciona quando você define métricas reais. **Se o HPA está medindo CPU mas o gargalo é I/O na base, você está empilhando pods inúteis.** O caminho é simples: observabilidade antes de escalabilidade.

Você não “ganha” escala — você a projeta. E para isso é obrigatório ter tracing, métricas e logs antes de liberar o HPA para brincar de multiplicar réplicas.

Implementação de Sênior: HPA com métrica correta, não mágica

A seguir, um exemplo real que uso em produção: escalonamento baseado em fila (RabbitMQ) via API customizada e metric server dedicado. Porque CPU quase nunca é o gargalo — mas fila estourada sempre é.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: worker-service
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Pods
      pods:
        metric:
          name: rabbitmq_queue_messages_ready
        target:
          type: AverageValue
          averageValue: 30

Esse HPA escala apenas quando a métrica certa dispara: quantidade de mensagens prontas para processamento na fila.

**Isso é escala de verdade: baseada no que o serviço faz, não no que o cluster acha que ele está fazendo.**

O Custo da Escolha: Kubernetes Não é de Graça e Muito Menos Simples

Escolher Kubernetes significa assumir complexidade operacional, curva de aprendizado e custo financeiro. O trade-off é claro:

Se você precisa de elasticidade fina e isolamento de workload: Kubernetes entrega.
Se sua aplicação é simples, estável e previsível: você está contratando over-engineering por esporte.
Se o negócio não exige escala elástica: o cluster vira dívida técnica disfarçada de modernidade.

**Kubernetes é poderoso, mas cobra aluguel caro.**

Direto das Trincheiras: 3 Dicas Práticas

Não habilite o HPA antes de instrumentar o serviço com métricas reais. Você vai escalar o sintoma, não a causa.
Se seu cluster vive estável com 2 réplicas, você provavelmente não precisava de Kubernetes.
Antes de migrar, desenhe o fluxo de negócio em um quadro branco. Sempre aparece um gargalo que YAML nenhum resolve.

Fontes e Leituras Relacionadas

Arquitetura de Software – Apenas mais um blog de tecnologia,
#TheDevConf 2025 |TDC SÃO PAULO – The Developer’s Conference

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

Kafka vs RabbitMQ: a verdade nua sobre escalabilidade em microserviços

Chega de romantizar mensageria. Quando o sistema começa a chiar, fila travando e consumidor engasgando, é aí que o arquiteto leva culpa. Kafka e RabbitMQ não são mágicos, têm propósitos distintos — e escolher errado vira dívida técnica que assombra por anos. Neste artigo, trago a visão de trincheira: onde cada um brilha, onde cada um quebra, e quando abandonar o hype e focar no que realmente resolve o problema do negócio.

Banco de dados

Mensageria em Microssistemas: Quando Ela Entrega Valor — e Quando Só Aumenta Sua Dívida Técnica

A verdade nua e crua: muita gente coloca mensageria em microserviços porque viu num diagrama bonito no slide do arquiteto da moda. Só que hype não paga boleto — e muito menos salva sistema mal modelado. Aqui eu explico onde a mensageria realmente resolve dor de negócio, quando ela vira over-engineering e como implementar sem transformar sua stack em um zoológico distribuído impossível de manter.

Discussões

A Ilusão do Low‑Code: Quando a Promessa de Velocidade Destrói Sua Arquitetura

Low‑code funciona… até o dia em que você precisa entender o que realmente está acontecendo lá dentro. Como arquiteto nas trincheiras, já vi mais projetos ruírem por dependência cega em plataformas mágicas do que por falta de framework moderno. Neste artigo, vou direto à dor: o low‑code vende eficiência, mas frequentemente entrega dívida técnica embrulhada para presente. Hora de desmontar o hype e mostrar onde ele realmente funciona — e onde vira armadilha arquitetural.