A falácia da escala

Hoje em dia, sempre que vamos começar um projeto de software, caímos na mesma discussão: qual escala esse software precisa atender?

E aí já começa o problema. Como bons engenheiros, tentamos prever todas as situações que o sistema poderia enfrentar. Mesmo sem ter dado nenhum passo ainda, já pensamos em:

• arquitetura distribuída no primeiro dia,

• camadas e camadas de pastas e módulos pra “garantir desacoplamento”,

• usar o mesmo banco NoSQL que empresas gigantes usam,

• copiar práticas que só fazem sentido em empresas que têm centenas de milhões de usuários.

Durante minha carreira inteira foi sempre igual:

“quantos usuários?”,

“quantas transações por segundo?”,

“quantos e-mails?”,

“quanto tráfego?”.

E quanto maior o cargo de quem respondia, mais absurdo o número e mais megalomaníaco o projeto ficava. Isso coloca qualquer desenvolvedor em um estado de ansiedade permanente: domínios demais, serviços demais, integrações demais, decisões demais baseadas em medo e não em fatos.

A realidade é simples:

na maior parte das empresas, ninguém sabe se o produto vai sobreviver o suficiente pra ter problema de escala.

Se você está numa startup com três clientes e caixa pra quatro meses, pouco importa escala, importa lançar rápido, receber feedback rápido e iterar rápido. Você nem sabe ainda se vai chegar no ponto onde escala vira um problema real.

Agora… Se você está no Nubank, Google, Meta, etc., aí sim é outro universo. A expectativa já nasce em “milhões”. Arquitetura, orçamento, roadmap e decisões técnicas já são pensadas pra isso desde o topo da cadeia. É alinhado com CEO, investidores, board, todo mundo.

Mas esse é 0.001% dos casos.

Na maior parte das empresas por onde já passei ou conversei com gente que passou, as decisões técnicas são feitas assim:

feeling > dados achismo > métrica medo > realidade

E quando isso acontece, surgem aberrações. Softwares que gastam milhões, ficam anos sendo desenvolvidos, nunca são usados e depois são simplesmente descartados. Eu já vivi isso: entrei numa empresa que tinha 191 nanosserviços criados por seis devs, quatro anos de trabalho, zero uso em produção e no fim jogaram tudo fora e voltaram pro legado que sempre pagou as contas.

O problema não é usar ferramentas avançadas.

O problema é usar porque “parece certo”.

O ponto central da Falácia da Escala é esse:

a maior parte das decisões sobre “escala” é tomada sem nenhum dado real.

As pessoas imaginam gargalos que talvez nunca existam. Antecipam 30 anos de problema pra um produto que mal começou.

E isso gera prejuízo, atraso e complexidade totalmente desnecessária.

E qual é o caminho certo, então?

Não existe fórmula, mas existe método.

1. Entender o contexto da empresa onde você está

Se você trabalha num lugar que não tem expectativa realista de chegar em milhões de usuários, você não precisa escrever código como se estivesse no Google. É outro jogo, outra realidade, outro objetivo.

2. Construir o mínimo necessário

Um sistema lean, simples, direto ao ponto. Sem firula, sem abstração antecipada, sem engenharia ornamental.

3. Tornar o sistema flexível e fácil de mudar

Extensível, pouco acoplado, fácil de iterar. A preocupação não é prever o futuro inteiro; a preocupação é garantir que, quando o futuro chegar, você consiga adaptar sem sofrimento.

4. Observabilidade desde o primeiro deploy

Com métricas, logs, traces e números reais, você sabe:

• quando o banco está sofrendo,

• quando um endpoint está lento,

• quando filas começam a acumular,

• quando realmente precisa escalar.

Sem dados, você adivinha. Com dados, você ajusta.

É isso que separa engenharia responsável de engenharia baseada em fantasia.

Nos próximos posts

Vou entrar nos vieses individuais que alimentam essa falácia, como:

• “banco relacional não escala”

• “monolitos não escalam”

• “microserviço desde o dia 1”

• camadas infinitas “pra desacoplar”

• hype-driven development

• copiar big tech sem motivo

E principalmente: como tomar decisões técnicas baseadas em realidade, não em paranoia.