Quando falamos de escalabilidade em tecnologia, a conversa rapidamente vai para infraestrutura. Quantas requests suportamos? Temos autoscaling? Podemos adicionar mais servidores? O banco de dados aguenta? São perguntas importantes. E vale fazer uma distinção: escalar capacidade computacional costuma ser relativamente simples; o estado — e especialmente o banco de dados — muitas vezes continua sendo uma das partes difíceis.

Mas, mesmo que resolvamos perfeitamente essa dimensão, ainda não sabemos se a empresa consegue escalar. Suportar mais tráfego e escalar um negócio são problemas diferentes.

Suponhamos que amanhã vendamos dez vezes mais

Imagine uma empresa que hoje processa 10.000 solicitações por mês e, como resultado de um crescimento extraordinário, passa a processar 100.000. A infraestrutura responde. A aplicação continua disponível e os tempos técnicos permanecem dentro do esperado.

A empresa escalou?

Ainda não sabemos.

Precisamos entender o que aconteceu com as exceções, atendimento ao cliente, fraude, conciliações, operações, segurança, dados e com as equipes que mantêm tudo isso funcionando. Porque, se as vendas aumentaram dez vezes, mas também precisamos de dez vezes mais pessoas para sustentá-las, tecnicamente suportamos mais volume.

Economicamente, talvez não tenhamos escalado.

Essa é a distinção que mais me interessa.

O problema aparece quando o crescimento se transforma em trabalho manual

Os sistemas costumam funcionar bem enquanto tudo segue o caminho esperado. O problema aparece com as exceções: uma solicitação que não pôde ser processada, um pagamento que não conciliou, um documento que não pôde ser validado ou uma integração que devolveu algo inesperado.

E aparece uma pessoa.

Quando temos cem casos e dois exigem intervenção manual, isso provavelmente não importa muito. Mas, se multiplicarmos o negócio por dez e essas exceções também se multiplicarem, uma pessoa pode virar cinco, cinco podem virar vinte e, eventualmente, uma equipe inteira pode ficar dedicada a compensar aquilo que o sistema não conseguiu resolver.

Para mim, esse é um sinal muito claro:

Quando o crescimento começa a transferir sistematicamente trabalho dos sistemas para as pessoas, precisamos voltar a olhar para o desenho.

Isso não significa que toda intervenção humana seja ruim. Algumas decisões exigem contexto, julgamento ou um nível de risco que torna perfeitamente razoável a participação de uma pessoa. O objetivo não deveria ser eliminar o ser humano do processo. Deveria ser reservar a intervenção humana para aquilo em que o julgamento realmente agrega valor.

Escalar é gerar alavancagem

Pense em uma fintech que administra uma carteira de crédito. Suponha que ela multiplique suas vendas por dez. Se, para administrar uma carteira dez vezes maior, também precisa multiplicar por dez sua equipe operacional, existe uma relação praticamente linear entre negócio e estrutura.

Agora imagine que a empresa venda dez vezes mais, processe dez vezes mais solicitações e administre uma carteira dez vezes maior, enquanto o trabalho exigido das equipes cresce apenas marginalmente.

Algo diferente está acontecendo.

A tecnologia está gerando alavancagem. É assim que gosto de pensar em escalabilidade:

Uma empresa escala quando sua capacidade de gerar negócio cresce muito mais rápido do que os recursos necessários para sustentá-lo.

Isso não significa que o headcount nunca deva crescer. Significa que volume e estrutura não deveriam ser obrigados a crescer na mesma proporção.

O custo por unidade conta uma história melhor

Uma forma prática de analisar isso é parar de olhar apenas para o custo total e começar a observar o custo por unidade de negócio. Suponha que hoje processemos 100.000 solicitações por mês. Entre infraestrutura e operação humana, cada solicitação nos custa USD 0,50:

  • USD 0,15 de tecnologia;
  • USD 0,35 de trabalho operacional.

Isso representa aproximadamente USD 50.000 por mês. Agora o negócio cresce dez vezes e passa a processar um milhão de solicitações. Se houver alavancagem real, parte dos custos fixos passa a ser distribuída por um volume muito maior. Talvez o custo unitário caia para USD 0,30. O negócio cresceu 10×, mas o custo associado passou de USD 50.000 para USD 300.000: cresceu 6×.

Isso pode ser um ótimo sinal.

Agora imagine o cenário contrário. As exceções aumentam, precisamos incorporar mais pessoas, surgem novos processos manuais e o custo por solicitação sobe para USD 0,70. Um milhão de solicitações agora custa USD 700.000 por mês.

A empresa cresceu.

Mas cada nova unidade de negócio ficou mais cara de produzir. A capability de Unit Economics do FinOps trata justamente dessa relação: conectar o gasto tecnológico com o valor gerado pelos produtos, serviços ou atividades da organização, em vez de analisar o gasto tecnológico isoladamente.

Uma conta de cloud maior não significa necessariamente que existe um problema. Pode ser simplesmente uma consequência do crescimento.

A pergunta mais relevante é:

O que acontece com o custo necessário para produzir cada nova unidade de negócio à medida que aumentamos a escala?

A alavancagem também introduz risco

Precisamos evitar transformar automação em um objetivo por si só. Suponha que automatizemos todas as exceções de um processo de originação de crédito. Eliminamos boa parte da intervenção manual e reduzimos significativamente os custos operacionais.

Excelente.

Mas agora uma decisão incorreta também pode ser executada automaticamente milhares de vezes. Um falso positivo de fraude pode bloquear clientes legítimos. Uma regra incorreta pode rejeitar solicitações válidas. Um erro de conciliação pode se propagar antes que alguém perceba. A pessoa que antes resolvia a exceção não representava apenas um custo.

Em alguns casos, também era um controle. Portanto, a pergunta não deveria ser apenas quanto conseguimos automatizar. Também precisamos medir a taxa de erro, o impacto potencial de decisões incorretas, os mecanismos de monitoramento e em quais situações uma operação deveria voltar para uma pessoa.

Escalar não significa eliminar controles. Significa desenhá-los para a nova escala.

Automatizar um processo ruim apenas o torna mais rápido

Poderíamos tentar resolver qualquer problema por meio de automação. Mas automação não garante escalabilidade. Se automatizarmos um processo mal desenhado, podemos simplesmente executar um processo ruim mais rapidamente. O DORA utiliza uma ideia parecida ao analisar a adoção de IA no desenvolvimento de software. O State of AI-assisted Software Development 2025, baseado em quase 5.000 profissionais de tecnologia, descreve a IA como um amplificador: ela pode potencializar organizações com boas capacidades, mas também amplificar problemas existentes.

A pesquisa encontrou melhorias no throughput de entrega, mas também um aumento na instabilidade. A extensão que faço dessa ideia é simples:

a tecnologia amplifica sistemas.

Por isso, antes de automatizar um processo, vale entender qual sistema estamos prestes a amplificar.

As dimensões que costumamos esquecer

Infraestrutura é apenas uma parte da escalabilidade. Existem pelo menos outras duas dimensões que muitas vezes só ficam visíveis depois que o negócio já cresceu.

Dados

Com poucos clientes, podemos sobreviver com informações dispersas, processos manuais, definições ambíguas ou conhecimento armazenado na cabeça de determinadas pessoas. Com dez vezes mais operação, isso começa a quebrar. Precisamos medir, auditar, detectar anomalias, automatizar decisões, construir modelos e entender melhor o que está acontecendo.

Para fazer tudo isso, precisamos ter pensado em como capturamos, armazenamos, governamos e disponibilizamos os dados. Uma empresa pode ter infraestrutura escalável e uma arquitetura de dados que não escala.

Organização

O mesmo acontece com as pessoas.

Uma equipe de cinco desenvolvedores pode se coordenar conversando. Uma equipe de cinquenta precisa de mecanismos diferentes: ownership, documentação, padrões, observabilidade, processos de desenvolvimento, plataformas internas e formas de compartilhar conhecimento. O DORA reportou em 2025 que 90% das organizações pesquisadas já haviam adotado plataformas internas e que 76% tinham equipes dedicadas a gerenciá-las.

Isso não significa que toda startup precise criar amanhã uma equipe de Platform Engineering. Significa que as práticas que funcionam com dez pessoas não necessariamente funcionam com cem. Existe ainda outra limitação: contratar também não escala instantaneamente. Uma nova pessoa pode precisar de semanas ou meses para atingir produtividade plena. Alguns perfis são escassos, e conhecimento crítico concentrado em duas pessoas não pode ser multiplicado simplesmente aprovando mais orçamento.

A escalabilidade humana não é apenas uma questão de quanto custa contratar. Também é uma questão de quanto tempo a organização leva para absorver novas pessoas e quanto conhecimento consegue transferir sem depender de indivíduos específicos.

O teste de 10×

Há uma pergunta extremamente simples que gosto de utilizar:

Se amanhã multiplicarmos o negócio por dez, o que mais precisaria ser multiplicado por dez?

A resposta funciona quase como um diagnóstico. Se precisarmos aumentar capacidade computacional, provavelmente conseguiremos resolver — embora, novamente, estado e banco de dados mereçam atenção especial. Mas, se também precisarmos multiplicar por dez a equipe operacional, as exceções manuais, os incidentes, o tratamento de fraude, os tempos de resposta ou os custos por transação, temos algo para revisar.

Nem tudo precisa permanecer constante. Isso seria irreal. A pergunta é quais variáveis estão crescendo linearmente com o negócio e se realmente deveriam crescer dessa forma. Podemos fazer o exercício em cinco dimensões:

  1. Tecnologia: qual infraestrutura precisa crescer?
  2. Custo: o que acontece com o custo por unidade?
  3. Pessoas: quais equipes precisam crescer e quanto?
  4. Processos: quais tarefas manuais e exceções se multiplicam?
  5. Risco: quais erros ou incidentes passam a ter mais impacto em escala?

A lista resultante dessas cinco perguntas diz muito mais sobre nossa capacidade de escalar do que saber quantas requests por segundo uma API consegue suportar.

Escalar não é suportar mais tráfego

Por isso, eu não definiria escalabilidade como a capacidade de suportar mais usuários ou mais requests.

Eu a definiria de outra forma:

Escalabilidade é a capacidade de aumentar significativamente o negócio sem aumentar na mesma proporção a complexidade, o custo e o esforço necessários para sustentá-lo.

Isso inclui infraestrutura, mas também arquitetura, processos, dados, segurança, pessoas e cultura. E muda a pergunta que um CTO deveria fazer.

Já não é apenas:

“Nossos sistemas suportariam dez vezes mais usuários?”

É:

“Nossa empresa conseguiria operar com dez vezes mais usuários?”

A diferença parece pequena.

Mas pode ser a diferença entre uma empresa que simplesmente está crescendo e uma empresa que realmente está preparada para escalar.

Fontes e leituras