O cálculo que assusta em entrevistas de System Design, mas não deveria

Existe um momento em entrevistas de System Design que costuma causar aquele frio na barriga.

Você está conversando sobre requisitos, APIs, bancos de dados e componentes quando o entrevistador pergunta:

Quantas requisições por segundo esse sistema precisa suportar?

Nesse momento, várias dúvidas aparecem ao mesmo tempo.

Quantos utilizadores devo considerar? Quantas ações cada pessoa realiza? Preciso chegar ao número exato? O que acontece se eu errar uma conta simples?

Essa etapa é conhecida como Back-of-the-Envelope Estimation, que podemos traduzir como uma estimativa rápida ou um cálculo de guardanapo.

Apesar de envolver números, ela não é realmente uma prova de matemática.

É uma forma de tornar o seu raciocínio visível.

Você não precisa acertar o número exato

Quando estimamos a escala de um sistema, não estamos tentando prever exatamente quantos servidores a aplicação utilizará daqui a três anos.

O objetivo é descobrir a ordem de grandeza do problema.

Existe uma diferença enorme entre projetar um sistema para:

300 requisições por segundo;
30 mil requisições por segundo;
300 mil requisições por segundo.

Da mesma forma, armazenar 50 GB é um problema completamente diferente de armazenar 50 PB.

A estimativa precisa ser boa o suficiente para ajudar a responder algumas perguntas:

O sistema realmente terá uma escala elevada?
O maior volume estará nas leituras ou nas escritas?
O armazenamento será um desafio relevante?
Precisaremos de cache?
A largura de banda poderá ser um gargalo?
Será necessário distribuir os dados entre várias regiões?

Antes mesmo de desenhar o primeiro componente, os números já começam a mostrar onde a arquitetura poderá ficar mais difícil.

O entrevistador quer acompanhar o seu raciocínio

Uma boa estimativa pode começar com uma frase simples:

Vou declarar algumas premissas para conseguirmos estimar a ordem de grandeza.

Essa frase muda completamente a conversa.

Você não está dizendo que conhece os números reais da empresa. Está apenas criando um cenário razoável para orientar o design.

Por exemplo:

300 milhões de utilizadores ativos por mês;
50% utilizam a aplicação diariamente;
cada utilizador realiza duas ações por dia;
o tráfego no horário de pico é duas vezes maior do que a média.

Caso o entrevistador prefira outras premissas, ele poderá ajustá-las. O método continuará exatamente o mesmo.

As suas premissas não precisam ser perfeitas. Elas precisam ser claras.

Um método simples para estimar a escala

Sempre que alguém pedir uma estimativa, você pode seguir esta sequência.

1. Calcule os utilizadores ativos por dia

Normalmente começamos com o número de utilizadores ativos por mês, chamado de Monthly Active Users, ou MAU.

DAU = MAU × percentagem de utilizadores ativos diariamente

Se tivermos 300 milhões de MAU e assumirmos que 50% utilizam o sistema todos os dias:

300 milhões × 50% = 150 milhões de DAU

Agora temos o número de Daily Active Users, ou DAU.

2. Calcule as ações realizadas por dia

Se cada utilizador realiza duas ações diariamente:

150 milhões × 2 = 300 milhões de ações por dia

3. Transforme ações diárias em QPS

Um dia possui 86.400 segundos.

Portanto:

QPS médio = requisições por dia ÷ 86.400

No nosso exemplo:

300 milhões ÷ 86.400 ≈ 3.500 QPS

Durante uma estimativa inicial, também podemos arredondar 86.400 para aproximadamente 100.000, ou 10⁵.

Isso facilita bastante o cálculo mental:

300 milhões ÷ 100 mil ≈ 3.000 QPS

O resultado não é exato, mas está na ordem de grandeza correta.

Em uma entrevista de System Design, isso costuma ser muito mais importante do que chegar ao último dígito.

4. Considere o horário de pico

O tráfego de uma aplicação não é distribuído de maneira uniforme durante o dia.

Uma aplicação pode receber mais acessos durante a noite, depois do envio de uma notificação ou durante algum evento importante.

Por isso, podemos aplicar um Peak Factor, normalmente entre duas e três vezes o tráfego médio.

Peak QPS = Average QPS × Peak Factor

Utilizando um fator de pico de duas vezes:

3.500 × 2 = 7.000 QPS no pico

Pronto. Já temos uma primeira noção da carga que o sistema deverá suportar.

Quando a estimativa revela o verdadeiro problema

Vamos adicionar armazenamento ao mesmo exemplo.

Imagine que:

10% das publicações possuem uma imagem ou outro conteúdo multimédia;
cada conteúdo possui aproximadamente 1 MB;
os dados serão armazenados durante cinco anos.

O armazenamento diário seria:

150 milhões de utilizadores
× 2 publicações por dia
× 10%
× 1 MB

= 30 TB por dia

Durante cinco anos:

30 TB × 365 × 5 ≈ 55 PB

Observe o que aconteceu.

O sistema possui aproximadamente 3.500 escritas por segundo, um número que pode parecer relativamente administrável.

Por outro lado, ele precisa armazenar aproximadamente 55 petabytes de conteúdo.

A estimativa acabou de mostrar que o maior desafio provavelmente não está no número de requisições. O problema mais complexo pode estar no armazenamento, na replicação, na distribuição e na entrega desses ficheiros.

Descobrimos isso antes de escolher banco de dados, cache, fila, linguagem de programação ou qualquer serviço de cloud.

Esse é o verdadeiro valor do Back-of-the-Envelope Estimation.

Os números que realmente vale a pena memorizar

Você não precisa decorar dezenas de fórmulas.

Um pequeno conjunto de números resolve a maior parte das estimativas.

86.400 segundos por dia

Esse é o número utilizado para transformar ações diárias em QPS.

Como atalho:

86.400 ≈ 100.000 ≈ 10⁵

Outra referência útil:

1 milhão de ações por dia ≈ 10 QPS
100 milhões de ações por dia ≈ 1.000 QPS
1 bilhão de ações por dia ≈ 10.000 QPS

A escada de armazenamento

Cada passo representa aproximadamente mil vezes mais dados:

KB → MB → GB → TB → PB

Se você mantiver essa sequência na cabeça, ficará muito mais fácil converter milhões de registos em gigabytes, terabytes ou petabytes.

O fator de pico

O QPS médio raramente representa o momento mais movimentado do sistema.

Como aproximação inicial:

Peak QPS ≈ Average QPS × 2 ou 3

Mais importante do que escolher exatamente duas ou três vezes é explicar a premissa utilizada.

O fator de replicação

Este é um dos termos mais fáceis de esquecer.

Se o sistema armazena três cópias de cada dado:

Armazenamento físico = armazenamento lógico × 3

Cinquenta terabytes de dados podem rapidamente transformar-se em 150 terabytes após a replicação.

Disponibilidade exige redundância. Redundância significa cópias. E cópias ocupam espaço.

A largura de banda

Outra conta simples, mas frequentemente esquecida:

Bandwidth = QPS × tamanho do payload

Mil respostas por segundo com 1 MB cada representam:

1.000 × 1 MB = 1 GB por segundo

Nesse cenário, o limite pode não estar na CPU ou no banco de dados. Ele pode estar na rede e no custo de transferência dos dados.

Erros comuns durante a estimativa

Alguns pequenos hábitos evitam grande parte dos problemas durante a entrevista.

Escreva sempre as unidades

O número 5 não significa nada sozinho.

São 5 KB, 5 MB, 5 GB, 5 mil requisições ou 5 servidores?

Uma unidade esquecida pode transformar uma conta correta numa conclusão completamente errada.

Arredonde sem culpa

Transforme uma conta como:

99.987 ÷ 9,1

em:

100.000 ÷ 10

Você está fazendo uma estimativa, não fechando a contabilidade anual de uma empresa.

Diga as premissas em voz alta

Uma frase como esta demonstra organização e maturidade:

Vou assumir que 40% dos utilizadores estão ativos diariamente e que o pico é aproximadamente três vezes maior do que a média.

Mesmo que os números mudem, o método continua válido.

Faça uma verificação de sanidade

Ao terminar, pergunte:

O resultado parece razoável?
Estou falando de centenas ou centenas de milhares de QPS?
O armazenamento deveria estar em gigabytes ou petabytes?
Esqueci o fator de replicação?
Estou misturando bits e bytes?
O sistema possui mais leituras ou escritas?
O tamanho do payload faz sentido?

Essa pequena pausa pode encontrar erros antes que eles afetem o restante do design.

Uma ferramenta para praticar o raciocínio

Para tornar esse processo mais visual, criei um pequeno conjunto de recursos para praticar estimativas de System Design.

O estimador interativo começa com o conhecido exemplo do Twitter e mostra cada etapa do cálculo.

Você pode alterar:

número de utilizadores;
percentagem de utilizadores ativos diariamente;
ações realizadas por utilizador;
proporção entre leituras e escritas;
tamanho do payload;
período de retenção;
fator de pico;
fator de replicação;
capacidade estimada de cada servidor.

Em vez de apresentar apenas o resultado, a ferramenta mostra como cada valor foi calculado.

Essa é uma parte importante do processo, porque o objetivo não é memorizar uma resposta pronta. O objetivo é entender como as premissas se transformam em números e como esses números influenciam a arquitetura.

Também preparei um poster imprimível em formato A4 com as principais fórmulas, referências de latência, níveis de disponibilidade, unidades e atalhos de cálculo mental.

A ideia é imprimir, colocar próximo à secretária e consultar com frequência até que os números comecem a parecer familiares.

Todo o material, incluindo o código-fonte, as fórmulas e um conjunto de exercícios de revisão, está disponível no meu repositório de estudos:

github.com/mhayk/system-design

Confiança não vem de decorar todas as respostas

A parte mais desconfortável de uma entrevista de System Design costuma ser não saber exatamente qual resposta o entrevistador espera.

Mas esse é justamente o ponto.

Na vida real, raramente começamos um projeto com todas as informações disponíveis. Trabalhamos com requisitos incompletos, premissas, métricas aproximadas e limites que mudam ao longo do tempo.

Uma boa estimativa demonstra que você consegue trabalhar com essa incerteza.

Você não precisa prever o futuro.

Não precisa acertar o número exato.

Não precisa fazer toda a matemática mentalmente e em silêncio.

Você precisa declarar as suas premissas, manter as unidades visíveis, arredondar com bom senso e explicar o que os números significam para a arquitetura.

Na próxima vez que alguém perguntar: