Escalar SaaS sem quebrar: quando o cliente chega, o que quebra é o dinheiro
Se você é dev, achou que eu estava falando de código. Não estou. O seu SaaS deu certo, o marketing bombou, o cliente chegou todo de uma vez. Se você não se preparou pra escalar, é aí que você quebra. Conto o que eu olho antes do pico, porque eu sofri isso na pele.
🎧 PREFERE OUVIR? · 15 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 15 minutos no canal @josimarjmv pra série Viver de software, viver de SaaS. Sem edição, como se fosse ao vivo. Assista e leia junto: aqui embaixo eu conto a mesma coisa por escrito e ponho o que eu fui conferir depois.
escalar um SaaS sem quebrar é estar pronto antes de o cliente chegar, porque empresa pequena que cai no pico não ganha segunda chance. A ordem que eu sigo: teste de stress no banco de dados (o gargalo principal), cluster com escrita num nó só e leitura nos outros, back-end que aceita escala horizontal, jobs com trava contra race condition, fila de espera no carrinho, proteção contra ataque no lançamento, pagamento processado por job e caça a conexão que não fecha. E fecho com teste de carga em cada camada separada e depois em todas ao mesmo tempo, com dashboard de tempo de resposta e timeout.
Quebrar não é o código. É o dinheiro
Vamos escalar o SaaS sem quebrar. E quando eu falo quebrar, se você é dev, achou que eu estava falando de código, né? Não estou. Estou falando de dinheiro. Código a gente sabe que não pode quebrar, mas hoje o código é o menor dos problemas.
Você está lá fazendo o seu software pra dar certo. Beleza, deu certo, vai escalar. E agora, como é que você não quebra? "Como assim, Josimar, de escalar quebra?" É, meu amigo. Se você não estiver preparado pra escalar, você quebra na hora que chegar cliente.
Vou dar minha carteirada antes: eu tenho empresa de tecnologia e respiro tecnologia desde os 18 anos de idade. Coordeno a equipe de desenvolvimento, suporte, venda e pós-venda, atendo órgão público e privado, tenho vários SaaS online. Não é papagaio de pirata digital: é experiência de quem já matou software, já criou software que deu certo e software que deu errado.
A hamburgueria que vendeu 3.000 sanduíches em duas horas
Vou começar com um exemplo que não é software. Você tem uma hamburgueria e mete uma promoção no iFood: o hambúrguer de R$ 49 sai por R$ 19,90. O que você acha que vai acontecer numa sexta, num sábado, num domingo? Vai entupir de venda.
Beleza. Primeira coisa: o gateway de pagamento aguenta? No caso do iFood ele já está tratado pra pancada, mas e se você tiver o seu próprio? Aí vem o resto:
- A minha cozinha está preparada?
- Eu tenho insumo pra entregar tudo isso?
- Eu tenho cozinheiro, cozinheira, chapeiro, chapeira pra fazer tudo num tempo hábil?
- A operação cabe na minha cozinha?
- Eu tenho delivery pra entregar tudo isso?
Você vendeu 3.000 sanduíches em duas horas. Pensa no tamanho da operação pra entregar 3.000 sanduíches em três, quatro horas. É loucura.
E acontece muito de a pessoa dar um tiro só, e é o tiro que mata o SaaS dela. Porque as pessoas hoje são sem paciência. Baixou o seu aplicativo, entrou no seu SaaS, não conseguiu testar? Muito possivelmente não volta. Você vai ter um pós-venda mandando e-mail, SMS, WhatsApp, mas a chance de ela voltar já caiu dramaticamente.
Empresa pequena que cai não ganha segunda chance
Quando o Google cai, ninguém está nem aí. Se o Gmail cair, "ah, tá bom". Mas quando é empresa pequena começando, o povo fala: "não presta, tchau". É injusto. O mundo é injusto. Mas a percepção das pessoas é essa.
Eu vejo isso no provedor de internet. Quando o YouTube não abre, as pessoas ligam no provedor: "meu YouTube não está acessando". A culpa não é do YouTube, é do provedor. Quando é uma empresa muito grande, não tem problema. Quando é um SaaS que está começando, aí a gente tem esse bendito problema. Por isso o seu primeiro pico de clientes não pode ser o dia em que o sistema cai.
O gargalo número um: o banco de dados
Agora vamos pro SaaS. Você desenvolveu, começa a aparecer muito usuário, você liberou teste grátis. A infraestrutura que você pôs aguenta tudo isso?
Em geral, o principal gargalo que a gente tem na hora de escalar um SaaS é o bendito do banco de dados. Lógico que tem um monte de camada, cache do banco, cache em memória, um monte de estratégia pra o SaaS não cair. Mas a primeira coisa que eu olharia é teste de stress no banco:
- Quantos inserts ele aceita ao mesmo tempo? Quantos selects?
- Seu banco é um Supabase, com latência de requisição entre servidores? Você pôs uma VM no Brasil e o banco em outro lugar?
- Ou o Supabase é self-hosted? Mesmo assim: você fez teste de stress?
- Seu banco é único ou é cluster?
Os riscos que me fazem não pôr Supabase em produção eu detalhei em Supabase em produção: os 3 riscos.
Cluster: escrita num lado só, leitura em todos os outros
Se o seu banco é cluster, ele está configurado contra split brain? E o proxy que fica na frente, se for clusterizado, está otimizado pra isso também? O que é split brain: você tem uma aplicação mal configurada que faz insert em três nós, coisas diferentes, com ids diferentes. Bum. Vai quebrar.
Meu amigo, se você for fazer um cluster SQL, a gente faz insert pra um lado só e o resto é select. Você nunca faz insert em dois lugares ao mesmo tempo quando está num ambiente clusterizado. Óbvio que aí tem que ter backup, redundância, monitoramento, um monte de coisa, mas a dica é essa.
Fui conferir depois como o PostgreSQL documenta isso: no modo hot standby (documentação oficial do PostgreSQL, consultada em 17/10/2026), o servidor em espera aceita conexão e roda só consultas de leitura. A escrita fica no primário. É o mesmo desenho: grava num lado, lê nos outros.
E tem cluster e cluster. Redis é outra tecnologia. Cluster de Elasticsearch aceita entrada em vários lugares ao mesmo tempo, mas não fica tudo no mesmo lugar, não é multimaster. Existe configuração de cluster SQL que aceita escrita em mais de um nó, mas aí são estruturas bem mais robustas e avançadas. O que eu aprendi passando a faca no meu cluster de Elastic está em passei a faca no cluster Elasticsearch.
Você precisa mesmo de um cluster?
Você sabe quando é a hora? Quantos usuários o seu sistema aguenta hoje? Só fazendo teste de carga pra descobrir. E teste de carga não é rodar o benchmark que vem numa pasta do projeto, pela mãe do guarda. Você tem que testar o banco pelo banco.
Teste de carga: cada camada, depois todas juntas
Vai aí outra dica. A gente não faz teste de carga só no front, nem só no back, nem só no banco. Faço no banco com as métricas, depois no proxy se tiver, depois no back-end. Tudo tem que ser medido, e não só de forma isolada.
E por fim, todo mundo ao mesmo tempo. Você tem que ter uma dashboard clara, mostrando as métricas e o timeout de cada um. E rodar um teste ponta a ponta com o Playwright num navegador de verdade, sem ser headless, pra testar a navegabilidade visual enquanto a carga está rolando. Porque uma coisa é o ataque, outra coisa é a navegação.
Sem métrica e sem log você não sabe nem onde quebrou. O que eu mando registrar está em sem log você está no escuro.
Back-end, jobs e o monolitão que só escala vertical
Preocupe-se se o back-end está funcionando bem. Ele aceita mais de uma réplica, escala horizontal, ou você fez um monolitão que só escala vertical? Isso é extremamente importante você saber. "Ah, escala horizontal, posso pôr uma réplica, duas, três." Legal.
E os jobs separados? Eles têm chave de travamento pra não haver race condition? Tem? Legal, aí você também escala os jobs na horizontal. Não tem? Pôr mais réplica só multiplica o problema. Isso eu contei com mais calma em autoscale não salva aplicação mal feita.
O carrinho, a fila de espera e o ataque no lançamento
Se o seu front é de ticket, de venda: você se preocupou em ver quantos usuários simultâneos o carrinho de compra aguenta? Eventualmente você vai precisar de uma fila de espera, igual tem em Black Friday, Ticketmaster, esses sites que vendem muito. "Ah, meu front recebe 100 mil requisições tranquilo, cuida de 100 mil usuários ao mesmo tempo no carrinho." Cuidado. É muita gente ao mesmo tempo pra você atender numa velocidade boa pra conversão.
E o que velocidade tem a ver? Tudo. Se o seu site começa a ficar lento, você começa a vender menos. Quanto mais lento o site e o checkout, menos credibilidade você passa e mais rápido o pessoal vai embora. Fui atrás do número: no estudo Milliseconds Make Millions, da Deloitte (página consultada em 17/10/2026), uma melhora de 0,1 segundo na velocidade do site mobile veio junto com 8,4% a mais de conversão no varejo e 10,1% em viagem.
No pico ainda tem mais coisa:
- Ataque no lançamento. Se é lançamento, prepare-se pra não deixar invadirem nem derrubarem o sistema, ou ele ficar lento por um ataque de negação de serviço, um DDoS.
- Gateway de pagamento. Está transacionando certinho? Você pôs os pagamentos num job separado ou vai fazer tudo síncrono, com tudo dependendo de uma coisa só? Isso complica bastante.
- Depois do pagamento, o uso. Deu certo, o cara vai logar e usar o sistema. Quanto o back-end aguenta nessa hora?
Às vezes não é a aplicação: é o proxy, ou a conexão que não fecha
É aquilo que eu falei no começo: às vezes tem um proxy mal configurado no meio do caminho deixando tudo lento, e não é a aplicação.
Ou o banco aguenta 100 mil requisições no teste, mas o código está porco, porque fizeram com IA de qualquer jeito. Tem um loop gigante que abre conexão e não fecha. Ao longo do tempo as conexões vão juntando e o banco cai. Isso acontece demais. É meio básico, mas acontece muito, principalmente com a galera do vibe code. O que eu confiro antes de subir código desses pra produção está em vibe coder: o que eu confiro antes de subir pra produção.
| Camada | O que eu pergunto antes do pico |
|---|---|
| Banco de dados | Quantos inserts e selects simultâneos aguenta? A latência até a aplicação é aceitável? É cluster? |
| Cluster e proxy | A escrita vai pra um nó só? O proxy está tunado e sem split brain? |
| Back-end | Aceita réplica e escala horizontal, ou é monolito que só cresce vertical? |
| Jobs | Têm trava contra race condition? Pagamento roda em job ou tudo síncrono? |
| Front e carrinho | Quantos usuários simultâneos? Precisa de fila de espera? Aguenta ataque no lançamento? |
| Código | Abre conexão e fecha? Tem loop que vai acumulando conexão? |
Eu sofri isso na pele
A parte mais difícil que tem, depois que a gente começa a vender, é escalar. Eu te falo porque eu sofri isso na pele. Hoje a gente atende cliente em 18, 19 países. Semana passada chegou um cliente da Mongólia, achei super interessante. Ao longo da vida, escalando uma CDN de vídeo, a gente aprendeu coisa pra caramba. E hoje a gente tem mais de 300 microsserviços pra rodar os nossos sistemas inteiros. Como eu hospedo esses 300 sem pagar GitHub, contei em GitLab próprio: 300 microsserviços.
"Ah, mas banco, cluster, proxy..." É, cara. Se você quer escalar o seu SaaS pra tirar nota 10, você precisa entender essas maldades. Pausa a leitura em cada item que eu falei aqui e conversa com o seu Claude Code, com o seu Gemini, com a IA que você estiver usando, pra ela te dar o passo a passo de tudo que você tem que otimizar. Esse é o caminho.
Se você quiser aprender isso pessoalmente comigo, tem a Imersão de SaaS, presencial em São Paulo, que a gente chama de SaaS em Produção: infra de escala, suporte, venda, marketing, jurídico, contábil, tudo que eu aprendi ao longo de 20 anos pra você pôr de fato o seu SaaS em produção. Formato, data e condição são os da página dela, não desta gravação.
Nota de cronologia
O vídeo foi ao ar em 16 de outubro de 2026 e este texto saiu em 17 de outubro de 2026. O "semana passada" do cliente da Mongólia é relativo à gravação. Os 18, 19 países e os mais de 300 microsserviços são o que eu disse na gravação.
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
O que significa um SaaS quebrar ao escalar?
Não é o código, é o dinheiro. O marketing dá certo, o cliente chega todo de uma vez e o sistema cai ou fica lento. Quem entrou, não conseguiu testar e foi embora dificilmente volta. Se você não está preparado pra escalar, você quebra justamente na hora que o cliente chega.
Qual é o principal gargalo na hora de escalar um SaaS?
Em geral, o banco de dados. Tem muita camada que ajuda, cache do banco, cache em memória, mas a primeira coisa que eu olho é teste de stress no banco: quantos inserts e quantos selects ele aguenta ao mesmo tempo, e se a latência entre a aplicação e o banco não está te matando.
Como evitar split brain num cluster de banco de dados?
No cluster SQL que eu monto, a escrita vai pra um lado só e a leitura usa todos os outros nós. Você nunca faz insert em dois lugares ao mesmo tempo. Aplicação mal configurada que grava em três nós com ids diferentes quebra. Com isso vem backup, redundância e monitoramento.
Como saber quantos usuários o meu SaaS aguenta?
Só fazendo teste de carga. E não é benchmark de pasta: é teste no banco pelo banco, depois no proxy se tiver, depois no back-end, depois no front, com as mesmas métricas. Por fim, tudo ao mesmo tempo, com uma dashboard mostrando tempo de resposta e timeout de cada camada.
Meu back-end precisa escalar horizontal?
Você precisa saber se ele aceita uma, duas, três réplicas ou se você fez um monolitão que só escala vertical. E os jobs têm que ter chave de travamento contra race condition, senão escalar os jobs na horizontal vira bagunça.
Por que velocidade do site importa na hora do pico de vendas?
Site e checkout lentos passam menos credibilidade e vendem menos. O estudo Milliseconds Make Millions, da Deloitte, mediu que 0,1 segundo a menos no site mobile aumentou em 8,4% a conversão no varejo. Por isso, carrinho que recebe muita gente ao mesmo tempo pode precisar de fila de espera.
Código feito com IA pode derrubar o banco de dados?
Pode, e eu vejo isso demais. O banco aguenta 100 mil requisições no teste, mas o código abre conexão num loop e não fecha. Ao longo do tempo as conexões vão juntando e o banco cai. É básico, mas acontece muito com a turma do vibe code.
Baseado na gravação do canal @josimarjmv publicada em 16/10/2026 (15min17), 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: a série viver de software, viver de SaaS; "quebrar" no sentido de dinheiro, não de código; a carteirada (tecnologia desde os 18 anos, equipes de desenvolvimento, suporte, venda e pós-venda, órgão público e privado, vários SaaS online); o exemplo da hamburgueria com o hambúrguer de R$ 49 a R$ 19,90 no iFood e os 3.000 sanduíches em duas horas; o tiro único e a falta de paciência do usuário; a percepção injusta com empresa pequena e o provedor culpado quando o YouTube não abre; o teste grátis; o banco de dados como gargalo principal, cache e teste de stress; a latência do Supabase com a VM em outro lugar e o Supabase self-hosted; o cluster com insert num lado só e select nos outros, o split brain e o proxy; Redis e Elasticsearch como outras tecnologias; o teste de carga por camada e de ponta a ponta, a dashboard com timeout e o Playwright sem headless; back-end horizontal ou monolito vertical; jobs com chave de travamento contra race condition; fila de espera no carrinho, Black Friday e Ticketmaster; velocidade e conversão; DDoS no lançamento; pagamento em job; proxy mal configurado; conexão que não fecha em código feito com IA e o vibe code; os 18, 19 países, o cliente da Mongólia, a CDN de vídeo e os mais de 300 microsserviços; e o convite para a imersão presencial em São Paulo. Na gravação eu também falei de preço e pagamento da imersão; isso é condição comercial e ficou fora deste texto. Na gravação eu disse que várias pesquisas comprovam a relação entre velocidade e venda, sem citar uma; o estudo abaixo é a minha checagem.
Apuração minha (17/10/2026): a página do estudo Milliseconds Make Millions, da Deloitte, descreve a análise de quatro semanas de dados de sites mobile de marcas de varejo, viagem, luxo e geração de leads na Europa e nos EUA e informa que, com 0,1 segundo de melhora na velocidade, a conversão no varejo subiu 8,4% e o ticket médio 9,2%, e a conversão em viagem subiu 10,1%. A documentação de hot standby do PostgreSQL define o modo como a capacidade de conectar no servidor em espera e rodar consultas somente de leitura. O diagrama das camadas e a tabela são organização minha, feita depois, em cima do que eu disse. O caso da Mongólia não foi conferido fora da gravação.