Escalar um SaaS depois do lançamento sem partir o produto

Toda a gente celebra o lançamento. Quase ninguém o avisa da parte que vem depois — esse ano estranho, de nervos à flor da pele, em que o produto que lhe trouxe os primeiros cem clientes começa a dobrar sob o peso dos mil seguintes. Nada de dramático acontece. As coisas tornam-se apenas mais lentas, mais instáveis, mais difíceis de mudar. Numa terça-feira qualquer apercebe-se de que uma funcionalidade que antes levava um dia leva agora uma semana, e ninguém sabe bem porquê. É aí, e não no lançamento, que a maioria dos produtos SaaS se ganha ou se perde em silêncio.

Sentámo-nos com muitos fundadores precisamente neste ponto. Não estão a falhar — é isso que confunde. A receita sobe, a equipa cresce, as demonstrações correm bem. Mas, por baixo, o produto geme. Os tickets de suporte sobem mais depressa do que os utilizadores. Os deploys que antes eram aborrecidos chegam agora com a respiração suspensa. A base de código que há um ano parecia engenhosa parece agora um campo de minas onde cada alteração ameaça despoletar outra coisa. Não fizeram nada de errado. Apenas ultrapassaram aquilo que construíram, e ninguém lhes disse que era suposto isso acontecer.

Este é, portanto, o guia que gostaríamos que mais fundadores tivessem antes de as fendas aparecerem. Não é sobre hiperescala, Kubernetes ou aquilo que algum unicórnio fez com cinquenta milhões de utilizadores. É sobre o meio aborrecido e decisivo — passar de funciona para poucos para funciona para muitos — sem reescrever tudo, sem afugentar os seus clientes nem esgotar a sua equipa. O objetivo não é uma arquitetura perfeita. É um produto que continua a crescer em vez de um que começa a partir-se em silêncio.

O que parte mesmo quando um SaaS cresce

Eis a parte que mais surpreende os fundadores: os problemas de escala quase nunca chegam como a falha dramática para que nos preparamos. O servidor não se incendeia. Em vez disso, o produto desenvolve uma espécie de febre persistente de baixo grau. Páginas que carregavam num instante começam a levar três segundos. Um relatório que corria bem para os primeiros clientes entra em timeout para o grande que acabou de assinar. O mesmo bug reaparece vezes sem conta porque duas partes do código dependem secretamente uma da outra de um modo que ninguém documentou.

O que de facto parte raramente são os seus servidores — são os seus pressupostos. No início, construiu para a forma dos seus primeiros utilizadores: umas poucas contas, dados pequenos, fluxos simples, todos mais ou menos iguais. O crescimento não acrescenta apenas mais do mesmo. Acrescenta variedade. Um cliente com dez vezes os dados. Uma equipa que usa uma funcionalidade de um modo que nunca imaginou. Um pico às nove da manhã de segunda-feira, quando todos entram ao mesmo tempo. Cada um viola em silêncio um pressuposto cimentado no seu código há um ano, quando violá-lo era impensável.

Os quatro sítios onde tende a manifestar-se primeiro são previsíveis. A base de dados é quase sempre o canário — consultas instantâneas em tabelas pequenas arrastam-se à medida que os dados crescem. O endpoint lento: uma ou duas páginas a fazer trabalho a mais por pedido, sem problema até o tráfego se acumular. O deploy frágil, em que lançar fosse o que fosse se tornou assustador porque o código está demasiado emaranhado para se raciocinar sobre ele. E a carga de suporte, que não é de todo infraestrutura mas é o sinal precoce mais sincero de que o produto já não corresponde ao modo como as pessoas o usam de facto.

A armadilha de resolver problemas que ainda não tem

Antes de falarmos de corrigir, um aviso que salvou mais produtos do que qualquer otimização. A maior ameaça a um SaaS em crescimento não é ignorar a escala — é persegui-la cedo demais. No momento em que um fundador sente o primeiro abrandamento, o instinto é agarrar a arquitetura que leu num famoso blogue de engenharia. Microsserviços. Uma fila de mensagens. Uma configuração multirregião. Fazer sharding da base de dados antes de ela ter um milhão de linhas.

É assim que se passam seis meses e uma fortuna a construir infraestrutura para uma escala que não se atingiu, enquanto o produto real deixa de avançar. Pior, tornou agora cada alteração futura mais difícil, porque um sistema distribuído é dramaticamente mais complexo de construir e de depurar do que o sistema simples que tinha. Trocou um problema que ainda não tinha por um garantido que tem hoje: nada é lançado.

A disciplina aqui é a mesma que faz os bons produtos, à partida: resolva o problema que tem à frente, não o que se sente lisonjeado a imaginar. Um monólito aborrecido e bem compreendido que pode mudar depressa escalará melhor do que um sistema distribuído da moda que tem medo de tocar. A complexidade é um custo que paga todos os dias, não uma compra única.

Meça antes de mudar o que quer que seja

Quase todos os fundadores que conhecemos nesta fase estão convencidos de que sabem onde está o problema. Estão errados em metade das vezes — não por descuido, mas porque a intuição é um péssimo profiler. A parte do código que parece lenta está muitas vezes bem; o verdadeiro culpado é alguma consulta silenciosa que corre quarenta vezes numa página em que ninguém pensou. Não se pode corrigir o que não se mediu, e adivinhar aqui é como as equipas passam semanas a otimizar a coisa errada.

Não precisa de uma stack de observabilidade sofisticada para começar. Precisa de três números aborrecidos sempre à frente. Que endpoints são mais lentos, e quão lentos sob tráfego real. Que consultas à base de dados consomem mais tempo total — não a consulta isolada mais lenta, mas aquela cujo tempo se soma ao longo de milhares de chamadas. E onde os erros acontecem de facto, com contexto suficiente para os reproduzir. Com estes três, o nevoeiro costuma dissipar-se dentro de um dia.

1. 1
   Ligue a monitorização básica

   Tempos de resposta por endpoint, taxas de erro e registo de consultas lentas na base de dados. As ferramentas alojadas fazem isto numa tarde. Não pode melhorar um número que não vê.
2. 2
   Encontre os três principais reais

   Ordene pelo tempo total consumido, não pela intuição. Três infratores concentram quase sempre a maior parte da dor. Aponte-os — esse é o seu verdadeiro roteiro.
3. 3
   Corrija um, volte a medir

   Mude uma só coisa, depois reveja os números. Confirme que ajudou antes de avançar. Duas alterações ao mesmo tempo e nunca saberá qual delas contou.
4. 4
   Pare quando estiver suficientemente bom

   Defina 'rápido que chegue' antes de começar — digamos, cada página abaixo de um segundo com a carga atual. Para além disso, otimizar é um sorvedouro de tempo, não uma vitória.

Esse último passo conta mais do que parece. O trabalho de desempenho é genuinamente viciante; há sempre mais um milissegundo a aparar. Mas os seus clientes não sentem a diferença entre 200 ms e 120 ms, e as horas que passa a persegui-la são horas que não dedica à funcionalidade que faria de facto crescer o negócio. Meça, corrija os três principais, declare vitória, siga em frente.

A base de dados é quase sempre a primeira parede

Se tivéssemos de apostar dinheiro em onde um SaaS em crescimento bate no seu primeiro teto real, apostaríamos na base de dados todas as vezes. É a parte do sistema onde as pequenas decisões iniciais se acumulam com mais dureza. Uma consulta sem índice corre num piscar de olhos sobre mil linhas e arrasta-se sobre um milhão. O código não mudou. Os dados, sim — e os dados só crescem.

A boa notícia é que a base de dados é também onde vivem as correções mais baratas e de maior impacto. A clássica é o índice em falta: uma única linha que transforma uma consulta de vários segundos numa instantânea, porque a base de dados deixa de percorrer cada linha para encontrar as poucas de que precisa. Logo a seguir vem o problema das consultas N+1 — uma página que, em vez de fazer uma pergunta, faz em silêncio à base de dados a mesma pequena pergunta centenas de vezes num ciclo. Ambos são comuns, ambos são invisíveis até olharmos, e ambos costumam corrigir-se num dia assim que os encontramos.

Há aqui uma sequência em que nos apoiar, e compensa segui-la por ordem em vez de saltar para o fim. Corrija primeiro as consultas — índices, N+1, o relatório lento. Depois acrescente cache para os dados que são lidos constantemente mas mudam raramente. Só depois disso faz sentido falar de réplicas de leitura, instâncias maiores ou separar os dados. A maioria dos produtos SaaS nunca precisa dos passos posteriores. Só precisavam dos primeiros bem feitos.

Escalar o produto significa escalar o modo como o muda

Eis a viragem que apanha os fundadores desprevenidos: passado certo ponto, escalar deixa de ser sobre o produto aguentar mais utilizadores e passa a ser sobre a sua equipa aguentar mais mudança. Quando eram o senhor e um programador, cada um tinha o sistema inteiro na cabeça. Podia mudar o que quisesse porque sabia o que iria tocar. Com cinco ou dez pessoas, esse modelo mental estilhaça-se — e o código que assumia que todos sabiam tudo torna-se um peso.

Esta é a verdadeira razão por que os deploys se tornam assustadores. Não é que o código tenha piorado de um dia para o outro; é que ninguém consegue já prever totalmente o raio de impacto de uma alteração. A solução não é heroísmo nem um congelamento dos lançamentos. É investir nos andaimes pouco glamorosos que permitem a uma equipa maior mover-se sem se pisarem uns aos outros: um conjunto de testes automatizados que apanha as roturas óbvias, deploys que são rotina em vez de cerimónia, e uma forma de desligar um mau lançamento em segundos em vez de correr atrás do prejuízo.

• Um conjunto de testes a cobrir o punhado de fluxos que seriam catastróficos se partissem — login, pagamento, ação central. Não tudo; os poucos críticos.
• Deploys que correm com um botão, não um ritual, para que lançar pequeno e com frequência se torne seguro em vez de angustiante.
• Uma forma rápida de reverter, para que um mau lançamento seja um evento de cinco minutos, não um incidente de uma noite inteira.
• Feature flags, para poder lançar código primeiro a alguns clientes e desligá-lo de imediato se se portar mal.
• Documentação suficiente para que as férias de uma pessoa não congelem uma área inteira do produto.

Nada disto aparece numa demonstração. Nada disto acrescenta diretamente uma funcionalidade. E é exatamente o trabalho que separa um produto que continua a acelerar de um que abranda a cada nova contratação. As equipas que escalam bem são as que tratam a sua capacidade de mudar o produto em segurança como uma funcionalidade em si — porque, em escala, é precisamente o que ela é.

Uma breve história desde o ponto de rutura

Para tornar isto concreto, eis um composto retirado de trabalho que realizámos — detalhes esbatidos, a forma fiel à realidade. Um pequeno SaaS para gerir equipas de assistência no terreno tinha lançado bem e crescido até umas centenas de empresas pagantes. Os fundadores estavam entusiasmados e exaustos em igual medida. Depois assinou o seu maior cliente de sempre: uma firma com mais utilizadores e mais dados históricos do que os seus dez clientes anteriores juntos.

Numa semana, o painel onde todos viviam tinha abrandado até se arrastar para esse cliente — e, curiosamente, para todos os outros também. Os tickets de suporte dispararam. Os fundadores partiram do princípio de que precisavam de um servidor muito maior e preparavam-se para uma rearquitetura dolorosa e dispendiosa. Foi nesse momento que fomos chamados, e o instinto era compreensível mas errado.

Não tocámos na arquitetura. Ligámos o registo de consultas lentas e observámos durante uma tarde. O culpado era quase embaraçoso de tão pequeno: o painel principal carregava a lista de trabalhos de cada utilizador com um clássico padrão N+1, disparando uma consulta por trabalho. Para um cliente pequeno isso significava umas dezenas de consultas inofensivas. Para o novo gigante, significava milhares por carregamento de página — o que, em infraestrutura partilhada, arrastava todo o sistema para baixo para toda a gente.

A lição que os fundadores tiraram não foi técnica. Foi que o assustador problema de escala que tinham imaginado — o que exigia uma reconstrução e uma ronda de financiamento — era, uma vez medido, uma correção de dois dias escondida atrás de um sintoma assustador. Estiveram a ponto de passar meses a resolver o problema errado. Essa lacuna, entre a crise imaginada e a medida, é onde se desperdiça a maior parte do dinheiro da escala.

Quando é mesmo altura de reconstruir uma peça

Toda esta cautela perante a escala prematura pode ler-se como nunca refactorizar, nunca reconstruir. Não é isso. Por vezes uma parte do produto chegou mesmo ao fim da sua vida, e remendá-la outra vez é a escolha cara. O truque está em distinguir um verdadeiro limite estrutural das dores de crescimento comuns que uma correção medida resolveria.

O sinal honesto é este: reconstrua um componente quando o custo de o mudar se tornou consistentemente mais alto do que o custo de o substituir. Não quando é feio — código feio que é estável e raramente tocado está bem. Procura uma parte do sistema onde cada alteração é lenta e arriscada, onde os mesmos bugs continuam a voltar, onde os novos programadores não conseguem trabalhar em segurança, e onde já tentou as correções mais baratas e bateu numa parede. Quando várias destas condições são verdadeiras ao mesmo tempo, uma reescrita focada dessa única peça é a decisão certa.

E quando reconstruir, reconstrua uma peça — não o produto. A reescrita completa de raiz é o canto de sereia da escala, aquilo que parece limpo e acaba por afundar um ano enquanto os concorrentes lançam. Substitua o único componente apodrecido, atrás de uma fronteira clara, enquanto o resto do produto continua a correr e a render. Cirúrgico, não heroico.

Perguntas frequentes