Como Estimar Capacidade sem Inventar Números

O problema

Muita gente trata estimativa de capacidade como se fosse prova de matemática.

O resultado é previsível:

• a pessoa fica nervosa
• tenta acertar um número lindo
• se enrola em conta que nem precisava

Em entrevista, o ponto não é esse.

O entrevistador não quer ver se você faz conta longa de cabeça.

Ele quer ver se você sabe:

• escolher quais números importam
• chegar em uma ordem de grandeza rápida
• usar essa ordem de grandeza para tomar decisão de arquitetura

Modelo mental

Estimativa boa é rastreável.

Ou seja, outra pessoa consegue olhar a sua conta e entender de onde saiu cada número.

Na prática, três perguntas quase sempre bastam para começar:

1. quantos usuários ativos eu tenho por dia?
2. quantas ações importantes cada usuário faz?
3. quanto pesa cada registro ou resposta?

Com isso, você costuma derivar:

• requests por segundo
• volume de escrita
• volume de leitura
• armazenamento por dia, mês e ano
• tráfego aproximado de rede

Se quiser uma frase simples:

Estimar capacidade não é descobrir o número verdadeiro. É descobrir o tamanho do problema cedo o bastante para não desenhar arquitetura no escuro.

Quebrando o problema

Comece por QPS

QPS significa quantas requisições por segundo o sistema recebe.

Uma forma simples de chegar lá é:

1. comece com ações por dia
2. divida por 86.400, que é a quantidade de segundos de um dia
3. aplique um fator de pico, porque tráfego real não chega distribuído de forma bonita

Exemplo:

• 10 milhões de usuários ativos por dia
• cada um cria 2 links por dia

Isso dá 20 milhões de criações por dia.

Agora:

• 20.000.000 / 86.400 ~= 231

A média da escrita fica perto de 231 writes/s.

Se você assumir pico de 5x, chega a algo perto de 1.150 writes/s.

Depois calcule storage

Storage costuma ser a conta mais simples e uma das mais úteis.

Você precisa saber:

• quantos registros novos entram por dia
• quanto pesa cada registro
• por quanto tempo os dados serão guardados

Suponha:

• 20 milhões de links por dia
• 600 bytes por registro

Conta:

• 20.000.000 x 600 bytes = 12.000.000.000 bytes

Ou seja, algo perto de 12 GB/dia.

Em um ano:

• 12 GB x 365 ~= 4,3 TB/ano

Isso já responde bastante coisa.

Não é preciso entrar em obsessão contábil para perceber se você está lidando com gigabytes confortáveis ou terabytes que pedem mais cuidado.

Depois pense em bandwidth

Bandwidth é volume de dados trafegando na rede.

A conta mental é parecida:

• quantas respostas por segundo
• quanto pesa cada resposta

Se o sistema faz 1 bilhão de redirects por dia e cada redirect custa perto de 1 KB, você já está falando de algo como 1 TB/dia no caminho de leitura.

Essa conta não precisa ser perfeita para ser útil.

Ela já pode justificar:

• cache
• edge
• resposta pequena
• analytics fora do caminho crítico

Pico importa mais do que média

Média ajuda a ter noção.

Mas sistema costuma quebrar no pico, não na média.

Por isso, uma frase simples costuma fortalecer muito a resposta:

Vou trabalhar com média e pico, porque arquitetura sofre no pico.

O fator exato não precisa ser sagrado.

Ele só precisa ser defendável.

Se você disser de onde tirou o multiplicador, mesmo que seja aproximado, a conta já soa madura.

Pare quando a conta já mudou a decisão

Essa parte é importante porque separa maturidade de performance de quadro.

Se a conta já te mostrou que:

• leitura domina escrita
• o volume de dados cresce rápido
• o caminho crítico não pode carregar processamento extra

então ela já cumpriu o papel dela.

Continuar refinando só para soar cuidadoso costuma desperdiçar tempo.

Em entrevista, excesso de conta sem mudança de decisão começa a jogar contra você.

Exemplo simples

Vamos montar uma estimativa inteira para um encurtador de URL.

Assumindo:

• 10 milhões de usuários ativos por dia
• cada usuário cria 2 links curtos por dia
• cada link recebe 50 redirects por dia, em média
• cada mapeamento pesa 600 bytes
• cada redirect trafega 1 KB
• pico de 5x

Escrita:

• 10M x 2 = 20M criações/dia
• 20M / 86.400 ~= 231 writes/s
• pico ~1.150 writes/s

Leitura:

• 20M links x 50 redirects = 1B redirects/dia
• 1B / 86.400 ~= 11.574 reads/s
• pico ~57.870 reads/s

Storage:

• 20M x 600 bytes = 12 GB/dia
• 12 GB x 365 ~= 4,3 TB/ano

Bandwidth:

• 1B x 1 KB = ~1 TB/dia

Só com isso, já dá para defender:

• leitura domina escrita
• cache no caminho de redirect faz sentido
• persistência cresce bastante ao longo do tempo
• analytics pesado não deve atrasar o redirect principal

Erros comuns

• Tentar acertar tudo com precisão falsa.
• Esquecer o pico e olhar só a média.
• Misturar requests por dia com requests por segundo sem converter unidade.
• Escolher números arbitrários sem declarar suposição.
• Continuar refinando conta depois que a arquitetura já ficou clara.

Como um senior pensa

Quem tem mais experiência não usa estimativa para performar.

Usa para reduzir risco cedo.

O tom costuma ser este:

Vou fazer uma conta de ordem de grandeza, separar média de pico e usar isso para decidir o que realmente precisa escalar.

Essa postura mostra critério.

Você não está tentando impressionar com matemática.

Está tentando colocar o sistema em um tamanho que permita tomar uma decisão defensável.

Esse é o ponto central: estimativa serve para reduzir cegueira, não para performar precisão.

O que o entrevistador quer ver

Em system design, estimativa de capacidade revela maturidade rápido.

Porque mostra se você:

• escolhe os números certos
• converte unidade sem se perder
• diferencia média de pico
• usa a conta para justificar arquitetura

A melhor estimativa não é a mais elegante. É a que deixa a próxima decisão mais óbvia.

Número aproximado com raciocínio claro vale mais do que precisão inventada com cara de certeza.