Autoscale não salva aplicação mal feita — eu escalo a minha
Vou dar a minha carteirada antes: eu tenho empresa de tecnologia, eu cuido tecnicamente dela e eu gerencio CDN no Brasil e nos Estados Unidos pessoalmente. É daí que eu falo. E o que eu vejo vender por aí é um conto: "é só adicionar réplicas". Não é. Kubernetes não salva aplicação mal feita, e quem aperta o botãozinho do autoscale sem resolver race condition, banco, banco em memória, sessão, pagamento, API e storage não escala — multiplica o próprio defeito e recebe a fatura. Aqui eu abro a lista inteira do que vem antes, e mostro como a minha fila de conversão de vídeo escala sem autoscale de nuvem.
🎧 PREFERE OUVIR? · 12 min · Podcast Em Produção
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Gravei esses 11 minutos no canal @josimarjmv em 24 de junho de 2026, direto pra câmera. Assista e leia junto: aqui embaixo eu conto a mesma coisa com mais calma, desenhei a lista do que vem antes do botão num diagrama e fui atrás de fonte em quatro pontos que merecem papel — a definição oficial de escala horizontal e vertical, o nome que a literatura dá pro controle de concorrência, o que dizem as boas práticas sobre sessão de login, e o que uma sonda de porta realmente prova.
adicionar pod não é escalar. Antes do autoscale eu tenho que resolver, uma por uma: race condition (dois processos pegando o mesmo trabalho em paralelo), banco de dados (cluster ou não, por onde entra insert e por onde entra select), banco em memória (sozinho ou cluster, ativo-ativo ou ativo-passivo), sessão de login (local nunca — ela tem que viver fora da réplica), pagamento, APIs externas, storage (local ou S3 remoto) e healthcheck de verdade (porta aberta não prova worker saudável). Só então eu decido entre escala horizontal (mais réplicas), escala vertical (mais potência) ou fila com fallback — e essa decisão nasce da arquitetura, não do painel da nuvem. Aplicação ruim não é salva por pod.
A carteirada primeiro: eu sou dono e eu ponho a mão na massa
Antes de qualquer coisa, de onde eu falo. Eu sou CEO de uma empresa de tecnologia, e sim, eu sou dono da empresa — se alguém não quiser que eu fale por ser dono, pronto, nem sou diretor. Só que eu sou hands-on: eu cuido tecnicamente. Eu gerencio pessoalmente um CDN no Brasil e nos Estados Unidos, eu boto a mão na massa, eu testo as ferramentas. Então eu vim falar de experiência minha de escala de aplicação, não de slide.
Isso começou numa pergunta da live que eu faço toda segunda-feira às 12h, onde eu respondo abertamente o que chega no canal durante a semana. Me perguntaram: "você já fez certificação AWS?" Não. E não por preguiça: pra mim não faz sentido usar AWS, porque o meu negócio demanda muito tráfego, muita requisição, muita banda — então a minha conta não fecha. Eu já detalhei essa aritmética quando eu migrei da nuvem pro on-premise e quando eu abri a conta por requisição que eu não pago.
E seja AWS, Google, Proxmox ou qualquer coisa que você for usar que fale de autoscale e réplica automática: não caia nesse conto achando que é só isso. Se você é desenvolvedor sênior, pode pular — você já sabe o que eu vou falar. Se você é júnior ou estagiário, é pra você. E se você é dono de negócio, é pra você também, porque a conta vai cair no seu colo.
O mito: "é só adicionar réplicas"
Vai no site da nuvem agora, pesquisa sobre autoscale. O que eles te colocam é isso: é só você adicionar réplicas. Adicionar pode, né? Quanto mais pod eu adicionar, mais réplica eu vou ter, mais eu vou escalar a minha aplicação. É isso que o anúncio diz. E é exatamente aí que o cara se enforca.
Antes de discutir o botão, vale fixar o vocabulário com a fonte na mão, porque muita gente usa "escalar" pra duas coisas diferentes. Apuração minha: a documentação do Kubernetes sobre Horizontal Pod Autoscaling define que escala horizontal é responder ao aumento de carga implantando mais pods, e que escala vertical, no mundo do Kubernetes, seria dar mais recurso — memória ou CPU — aos pods que já estão rodando. A mesma página avisa, com todas as letras, que o autoscaling horizontal não se aplica a objetos que não podem ser escalados. Ou seja: o próprio manual já começa colocando limite no botão que o anúncio vende como mágica.
O meu recado é um degrau antes desse. Mesmo onde o autoscale se aplica, ele só funciona se a sua aplicação aguentar ser duas. E é aqui que entra uma palavrinha.
Race condition: a palavrinha que derruba a festa
Aí, meu amigo, entra uma palavrinha que chama race condition. O que é race condition? Bem bem bem singelo: dois caras vão pegar o mesmo serviço pra fazer em paralelo. Pronto. É isso que você precisa resolver antes de mexer com escala.
Repare no detalhe cruel: com uma réplica só, esse defeito nunca aparece. Tem um processo, ele pega o trabalho, ele faz, acabou. No segundo em que você sobe a segunda réplica, os dois podem pegar o mesmo trabalho — e aí dobra cobrança, dobra e-mail, dobra conversão, grava duas linhas onde devia ter uma. O autoscale não criou nada: ele multiplicou o que já estava lá, e você só descobre no pico, que é justamente quando você não quer descobrir.
E esse controle tem que obedecer a uma regra explícita, porque o seu processo pode morrer, pode quebrar, pode travar, pode dar timeout no meio do trabalho. Apuração minha, pra você saber o nome do que procurar: a documentação do Redis descreve o lock distribuído e o algoritmo Redlock e lista as três garantias que um lock desses precisa ter — exclusão mútua (num dado momento só um cliente segura o lock), liberdade de deadlock (sempre é possível adquirir o lock de novo, mesmo que o cliente que travou o recurso morra ou fique particionado) e tolerância a falha (enquanto a maioria dos nós estiver de pé, dá pra pegar e soltar lock). Leia as três devagar: são exatamente os três jeitos pelos quais a sua fila vai te trair quando você meter réplica sem pensar.
A lista que vem ANTES do botão: banco, memória, sessão, storage
E aí a gente entra num problema grande, porque você pode ter race condition em várias coisas. Vou na ordem em que isso me aparece na vida real:
- Banco de dados. Insert ou select? É cluster ou não? Qual banco é? MySQL, Mongo, Elasticsearch? (De cluster de Elasticsearch eu entendo o preço: eu passei a faca em 6 TB.) E se você está num banco remoto de terceiro com performance horrorosa, a réplica nova só vai fazer a lentidão render mais rápido — eu escrevi o porquê em por que eu não uso GitHub, Supabase ou Firebase em produção.
- Banco em memória. Tem? Ele é sozinho ou cluster? É ativo-ativo ou ativo-passivo? A biblioteca que fala com ele sabe disso? Você vai fazer insert por onde? Select por onde? Olha, a gente nem chegou na aplicação ainda.
- Sessão de login. O backend vai escalar, beleza — mas o login está salvo em arquivo local ou remoto? Se é local, a segunda réplica não conhece o seu usuário. Se você está no Laravel, o framework tem configuração nativa pra isso; framework fantástico nesse ponto.
- Pagamento e APIs externas. Toda chamada que sai da sua casa é um lugar onde a duplicação custa dinheiro de verdade.
- Storage. Seu storage é local ou você usa um S3 remoto? Disco local e réplica horizontal não se conversam.
Dois pontos dessa lista eu fui checar fora da minha cabeça, porque são os que mais derrubam gente boa. Apuração minha sobre sessão: o Twelve-Factor App, no fator "Processes", é taxativo — processos de doze fatores são sem estado e não compartilham nada, o que precisa persistir tem que ficar num serviço de apoio com estado, tipicamente um banco, e sticky session é violação do modelo e nunca deveria ser usada nem confiada; dado de sessão, diz o texto, é bom candidato a um armazenamento com expiração por tempo, tipo Memcached ou Redis. Ou seja: aquele truque de amarrar o usuário na mesma máquina pra "resolver" o login não é solução, é dívida.
Apuração minha sobre o banco em memória: na gravação eu citei o tal projeto que fizeram pra continuar gratuito depois da mudança de licença do Redis e não lembrei o nome na hora. O nome é Valkey: a Linux Foundation anunciou a comunidade em 28 de março de 2024, como alternativa open source ao Redis que continua o desenvolvimento a partir do Redis 7.2.4 sob licença BSD 3-clause, depois da mudança de licença da Redis Inc., com gente da AWS, Google Cloud, Oracle, Ericsson e Snap dentro. Fica anotado, porque a pergunta "ativo-ativo ou ativo-passivo?" você vai ter que responder nele também.
Horizontal, vertical ou nenhuma das duas: a análise que ninguém faz
Antes de entrar no meu exemplo, o básico que muita gente pula. A gente tem dois tipos de escala: a horizontal, que é quando você aumenta réplicas, e a vertical, que é quando você aumenta potência — mais cores, mais memória, mais GPU, um hardware mais potente.
E cabe sempre, em cada aplicação, fazer uma análise: quando eu preciso de fato de escala horizontal, quando eu preciso escalar vertical, e quando eu preciso apenas de um fallback, sem mexer com escala horizontal nenhuma. Essa análise parte de uma arquitetura de sistema bem feita: qual é o propósito do sistema, qual problema ele resolve, quantos usuários eu vou atender ao mesmo tempo, é tempo real ou eu tenho que construir uma fila? E essa fila vai trabalhar com fallback, com escala vertical ou com escala horizontal?
Tudo isso a gente tem que colocar antes de apertar o botãozinho do autoscale. Senão não vai adiantar nada: você vai subir escala lá e vai quebrar todo o seu sistema, se ele não for bem feito. Sobre começar pela arquitetura em vez de começar pelo código, eu já escrevi o erro mais caro que eu vejo em criar software com IA.
O meu caso: a fila de conversão que escala infinito (enquanto tiver hardware)
Agora o exemplo meu, que é onde a teoria encosta na fatura. Eu tenho uma plataforma de hospedagem de vídeo que não cobra tráfego. Quando você sobe um vídeo nela, ele vai pro nosso próprio S3, seja em upload uniparte ou multiparte, e a partir dele entra numa fila de conversão.
Essa fila tem escala horizontal praticamente infinita — e esse é um caso em que eu realmente preciso dela. Só que eu não tenho o autoscale da AWS ali, porque é muito caro: AWS é caro, Google Cloud é caro, Azure é caro. Então eu tenho a minha própria infraestrutura — é por isso que eu falei que eu cuido de CDN no Brasil e nos Estados Unidos. Ali eu escalo praticamente infinito enquanto tiver hardware: horizontal, eu saio metendo réplica. Quanto mais réplica, mais worker trabalhando, mais conversão de vídeo eu faço.
No meu caso o complicado é hardware: tem que meter GPU lá, e GPU é um negócio caro. Então eu escalo com previsão, não com susto. Hoje eu tive um pico de 100 vídeos ao mesmo tempo pra converter, de usuários que mandaram. Entrou cliente novo, entraram 10, 15 clientes novos, e eles estão mandando vídeo pra caramba. Aí é olhar a previsão e dizer: vamos escalar isso aqui. Esse é o uso legítimo de escala horizontal — worker consumindo fila, com o race condition já resolvido antes. Quem quiser ver o que o descuido nessa camada causa do lado do espectador, eu destrinchei em de onde vêm os 40 segundos de delay da Cazé TV.
Healthcheck que mente: a sua checagem olha a porta ou o worker?
Escala horizontal exige controle de race condition, e exige mais: você precisa aceitar que o processo pode morrer, pode quebrar, a aplicação pode travar, pode dar timeout. Você está usando pod? Está usando a rede interna dele ou rede host? Está usando Docker e o seu Docker travou, o contêiner perdeu comunicação? Você tem uma healthcheck que garante a comunicação do contêiner com o mundo externo?
E aí vem a pergunta que eu faço pra todo mundo: a sua healthcheck realmente checa se aquele worker está saudável, ou só checa se o processo na porta tal está rodando? Entende a diferença? Porta aberta com worker morto é o pior dos mundos, porque o balanceador continua mandando trabalho pra uma réplica que não vai fazer nada.
Apuração minha, com a fonte: a documentação do Kubernetes sobre probes separa as duas coisas que a maioria mistura — a sonda de liveness existe pra decidir quando reiniciar o contêiner (ela pega, por exemplo, o deadlock, em que a aplicação está rodando mas não consegue progredir), e a de readiness existe pra decidir quando o contêiner está pronto pra aceitar tráfego; se a readiness falha, o endereço do pod é removido dos EndpointSlices dos serviços, e ele para de receber requisição. E o mecanismo tcpSocket é exatamente o que o nome diz: uma conexão TCP na porta. Abriu a porta, passou a sonda. É por isso que eu insisto: checar porta não é checar saúde — saúde é o worker provando que fez, e isso se prova com log e observabilidade, assunto dos 30 GB de log que eu tive que ler pra achar um bug.
Por requisição ou por worker: onde entra o balanceamento
Resolvida a saúde, vem a pergunta de desenho: o que eu vou escalar é por requisição ou é por worker? Se é por requisição, tem um proxy na frente. Se é por worker, você cria a fila — em qualquer sistema de fila, tanto faz — e ele vai puxando os trabalhos a serem feitos. E se o que escala é uma API externa, essa API faz balanço de carga do lado dela ou não?
Aí a pergunta fica: onde é que eu faço isso? É no proxy, é em round-robin de DNS, ou você vai contratar um load balancer na nuvem? Eu acho caro, e eu já mostrei que a conta do intermediário aparece em lugares que ninguém lê, nos limites da Cloudflare que ninguém te conta. Mas o ponto não é a marca: tudo isso parte de uma arquitetura bem feita antes de botar a mão na massa.
Era do vibe coder: "na minha máquina roda" nunca esteve tão em alta
A gente está na era dos vibe coders, na era do software fácil. Fazer software está se tornando commodity: qualquer pessoa minimamente curiosa, que domina um pouco de tecnologia, faz. E eu acho isso bom — só que tem um detalhe.
Entre você fazer alguma coisa e dizer "na minha máquina roda" e botar em produção hoje, tem um oceano. Aquela brincadeira antigaça dos primórdios do desenvolvimento nunca esteve tão em alta quanto agora. Não é a mesma coisa rodar na máquina e rodar em produção — e o autoscale é justamente onde essa diferença cobra os juros. Eu já escrevi sobre os dois lados dessa moeda: o sabor programador que cospe código e não sabe a receita e o medo de subir em produção, que é o que esse pessoal vai sentir no primeiro pico.
(Um parêntese de transparência, porque me perguntam: os meus vídeos não são cortados. Tem corte no início, corte no fim, e o resto é gravado direto, como se fosse ao vivo, com duas câmeras. Não dá tempo de ficar cortando — a ideia é gerar valor e mostrar transparência, com engasgo e tudo.)
Quem vai valer dinheiro: o cara que entende arquitetura
Então não caia no mito do autoscale, principalmente você que está começando. Escalar aplicação não é colocar mais pod. Aplicação ruim não é salva por pod. A aplicação tem que ser bem estruturada, bem feita, e cada vez mais bem feita.
E tem uma consequência de carreira nisso, que é o que eu chamo de redenção dos tech leads. O tech lead, o arquiteto de software, esse cara vai valer muito no mercado, porque ele domina o negócio e tem visão de arquitetura — ele entende isso que eu acabei de falar. Enquanto isso, o cara que só faz "códigozinho" faz parte da leva de demissão que está acontecendo no mundo da tecnologia, porque ele é só digitador de código — e a gente não precisa de mais digitador de código. A gente precisa de gente que entenda de negócio e de arquitetura. Aí é empreendedor. Eu preciso de parceiros pra tocar os negócios em parceria, e é esse o futuro que eu vejo pela frente. Eu já expliquei por que, na contratação, eu fui parar do outro lado disso em o especialista acabou: eu só contrato full stack e em infraestrutura, o novo superpoder na era da IA.
Um adendo rápido, porque é a pergunta que sempre vem depois. Você quer aprender a escalar infraestrutura de verdade, essa coisa que eu estou falando aqui? É o conteúdo da minha imersão de infraestrutura: presencial em São Paulo, três dias, mão na massa, abordando do zero — BGP, NIC.br, homologação de ASN, compra de servidor, tamanho de rack (1U, 2U, 3U, 4U, pra quantas unidades?), cabo DAC, placa de 1, 10 ou 40 Gb, switch — Huawei, Juniper, Mikrotik —, pra você ter a sua própria mini Amazon dentro do seu negócio. Repare: nem entrei na aplicação, isso é só infraestrutura. Preço, data e condição eu não repito por aqui: essa informação é final e fica na página da imersão. Tem também as de agência de site, chatbot e SaaS, mas a que fala deste tema aqui é a de infraestrutura.
E se você preferir ir sozinho, vai com a lista do diagrama na mão: resolve, decide, só então escala. Um grande abraço, e até a próxima — tem mais dessa linha aqui no blog.
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Ver as lives no canal @josimarjmv →Perguntas frequentes
Autoscale resolve aplicação mal feita?
O que é race condition e por que ela vem antes do autoscale?
Escala horizontal ou escala vertical: como eu decido?
O que eu tenho que resolver antes de ligar réplica?
Onde eu guardo a sessão de login quando a aplicação escala?
Meu healthcheck está certo? Porta aberta é suficiente?
Preciso do autoscale da AWS pra escalar de verdade?
Eu sou júnior. Esse assunto é pra mim?
Baseado na gravação do canal @josimarjmv publicada em 24/06/2026 (11min42), com transcrição própria das legendas do próprio vídeo.
O que veio da gravação e o que é apuração minha, com as fontes
Da gravação: o mito do autoscale e a frase de que Kubernetes não salva aplicação mal feita; eu ser CEO e dono de uma empresa de tecnologia, cuidar tecnicamente dela, gerenciar pessoalmente CDN no Brasil e nos Estados Unidos, botar a mão na massa e testar as ferramentas; a live de toda segunda-feira às 12h em que eu respondo o que chega no canal; a pergunta sobre certificação AWS e a minha resposta de que não faz sentido pra mim porque o meu negócio demanda muito tráfego, muita requisição e muita banda, então a minha conta não fecha; o aviso de não cair no conto do autoscale e da réplica automática em AWS, Google, Proxmox ou qualquer nuvem; o recorte de público — sênior já sabe, júnior e estagiário é pra quem serve, e dono de negócio porque a conta cai no colo dele; o anúncio de que é só adicionar réplicas e que mais pod seria mais escala; a definição singela de race condition como dois caras pegando o mesmo serviço pra fazer em paralelo e a ordem de resolver isso antes de mexer com escala; a lista do que precisa estar resolvido — insert e select de banco, cluster ou não, qual banco, MySQL, Mongo e Elasticsearch, banco em memória sozinho ou cluster, ativo-ativo ou ativo-passivo, insert e select por onde, sessões de login salvas local ou remoto, o Laravel ter configuração nativa pra sessão, pagamento, APIs que vão se comunicar e storage local ou S3 remoto; o comentário de que a base remota de terceiro com performance horrorosa já virou vídeo meu; os dois tipos de escala, horizontal como aumentar réplicas e vertical como aumentar potência com mais cores, memória, GPU ou hardware mais potente; a análise por aplicação entre horizontal, vertical e apenas fallback, partindo de arquitetura bem feita, com propósito do sistema, problema resolvido, usuários simultâneos, tempo real ou fila, e a fila com fallback, vertical ou horizontal; o meu caso da plataforma de hospedagem de vídeo que não cobra tráfego, com upload uniparte ou multiparte no S3 próprio, fila de conversão com escala horizontal praticamente infinita, sem autoscale da AWS por ser muito caro, com infraestrutura própria, mais réplica significando mais worker e mais conversão, a complicação de GPU cara, o pico de 100 vídeos ao mesmo tempo e a entrada de 10 a 15 clientes novos mandando vídeo; o processo que pode morrer, quebrar, travar ou dar timeout, o uso de pod com rede interna ou rede host, o Docker travado e o contêiner que perdeu comunicação, e a pergunta se a healthcheck checa o worker saudável ou só o processo na porta; a separação entre escalar por requisição com proxy na frente e escalar por worker consumindo fila, a dúvida sobre a API externa fazer balanço de carga, e onde fazer isso — proxy, round-robin de DNS ou load balancer contratado, que eu considero caro; a era dos vibe coders, o software virando commodity, qualquer pessoa curiosa conseguindo fazer, e a distância entre "na minha máquina roda" e produção; a transparência de que os meus vídeos não são cortados, só início e fim, gravados direto como se fossem ao vivo com duas câmeras; o fecho de que escalar não é colocar mais pod, que aplicação ruim não é salva por pod, a redenção dos tech leads com o arquiteto valendo muito no mercado por ter visão de arquitetura, o digitador de código entrando na leva de demissão, a necessidade de gente que entenda de negócio e arquitetura, e a busca por parceiros; e o adendo da imersão presencial de três dias em São Paulo sobre infraestrutura, com BGP, NIC.br, homologação de ASN, compra de servidor, tamanho de rack em unidades, cabo DAC, placa de 1, 10 ou 40 Gb, switch Huawei, Juniper ou Mikrotik, e a própria mini Amazon dentro do negócio.
Apuração minha (01/10/2026): sobre as definições de escala, a fonte é a documentação oficial do Kubernetes sobre Horizontal Pod Autoscaling, que define escala horizontal como responder ao aumento de carga implantando mais pods, escala vertical como atribuir mais recurso (memória ou CPU) aos pods que já rodam, e afirma que o autoscaling horizontal não se aplica a objetos que não podem ser escalados, como um DaemonSet. Sobre o nome do controle de concorrência que eu descrevi, a referência pública é o padrão de lock distribuído com Redis (Redlock), que lista as três garantias necessárias: exclusão mútua (só um cliente segura o lock por vez), liberdade de deadlock (sempre é possível adquirir o lock de novo, mesmo que o cliente que travou o recurso caia ou fique particionado) e tolerância a falha (com a maioria dos nós de pé, clientes conseguem adquirir e liberar locks). Sobre sessão de login em aplicação que escala, a fonte é o fator Processes do Twelve-Factor App, que afirma que processos de doze fatores são sem estado e não compartilham nada, que o dado que precisa persistir deve ficar num serviço de apoio com estado (tipicamente um banco) e que sticky sessions são violação do modelo e nunca deveriam ser usadas nem confiadas, sendo sessão um bom candidato a armazenamento com expiração por tempo como Memcached ou Redis. Sobre healthcheck, a fonte é a documentação do Kubernetes sobre probes: liveness determina quando reiniciar um contêiner (pegando, por exemplo, deadlock em aplicação que roda mas não progride), readiness determina quando o contêiner está pronto pra aceitar tráfego e, ao falhar, faz o endereço do pod ser removido dos EndpointSlices dos serviços, e o mecanismo tcpSocket é uma checagem de conexão TCP na porta. E sobre o projeto cujo nome eu não lembrei na gravação: é o Valkey — a Linux Foundation anunciou a comunidade em 28/03/2024 como alternativa open source ao Redis, continuando o desenvolvimento a partir do Redis 7.2.4 sob licença BSD 3-clause depois da mudança de licença da Redis Inc., com apoio de AWS, Google Cloud, Oracle, Ericsson e Snap. As quatro checagens são minhas e não estão na gravação. Sobre a minha imersão eu não repito preço, data nem condição: essa informação é final e fica na página da imersão de infraestrutura.