Back-of-envelope: cálculos que convencem
- ⬜🗺️ Framework de system design interview(System Design Interview Prep)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Por que back-of-envelope é a skill mais importante em System Design
Em uma entrevista de System Design de 45 minutos, você não vai escrever código. Você vai fazer trade-offs. E todo trade-off bom começa com magnitude: 100 QPS é diferente de 100k QPS. 1 TB é diferente de 1 PB. Quem não sabe calcular isso em 30 segundos, perde 10 minutos discutindo coisa errada.
Mas o ponto não é memorizar números ou fazer aritmética impressiva. O ponto é usar o número pra tomar decisão arquitetural. "3 TB/dia de escrita" só vale se você concluir com "portanto, não é single-node MySQL".
Teste de ouro: se você fez uma conta e não disse a próxima decisão a partir dela, você ainda não terminou o raciocínio.
Os 3 pilares: latência, throughput, storage
Todo sistema responde a 3 perguntas de magnitude. Saiba responder cada uma em ≤ 60 segundos.
Regra de ouro: RAM é ~1000x mais rápida que SSD, que é ~100x mais rápida que HDD, que é ~10x mais rápida que cross-region. Três ordens de magnitude separam cada camada.
Powers of 10 — a única multiplicação que você precisa dominar
Engenheiros sêniores convertem 10^6 × 10^3 = 10^9 em milésimo de segundo. Se você faz "10 milhões vezes 5 mil" no dedo, perdeu o ritmo da entrevista.
| Expoente | Nome | Bytes | Contexto |
|---|---|---|---|
| 10³ | kilo (K) | KB | 1 linha de DB ≈ 1 KB |
| 10⁶ | mega (M) | MB | 1M users × 1KB = 1 GB |
| 10⁹ | giga (G) | GB | 1B rows × 1KB = 1 TB |
| 10¹² | tera (T) | TB | 1 dia de logs web-scale |
| 10¹⁵ | peta (P) | PB | 1 ano de logs Netflix-scale |
Segundos em expoentes:
Truque canônico: 10k QPS × 1 dia ≈ 1 bilhão de requests. Vale memorizar. "10 mil/s durante um dia = 1B" aparece em toda entrevista de scale.
Framework de 4 passos na entrevista
Todo exercício de back-of-envelope em entrevista segue a mesma estrutura. Pratique até virar automático.
- Pergunte premissas antes de calcular — "Quantos usuários? DAU ou MAU? Média ou pico? Leitura ou escrita dominante?" Sem premissa, conta não convence.
- Calcule em voz alta com unidades — "100M DAU, cada um faz 20 requests/dia: 2B req/dia ÷ 86k s/dia ≈ 23k QPS média. Pico 3x = 70k QPS". Explicite cada passo.
- Arredonde agressivamente — 86.400 vira 10⁵, 365 vira 3×10². Precisão vira inimiga da velocidade. Erro de ±2x é aceitável.
- Conecte com decisão arquitetural — "70k QPS de escrita é > que 1 MySQL primary. Preciso sharding OU log-structured store como Cassandra OU stream Kafka + processamento async".
Por que estimativa aproximada é considerada a habilidade mais importante nesse tipo de entrevista?
Exemplo ao vivo: Twitter-like feed
Pergunta: "Desenhe um sistema tipo Twitter. Assuma 200M DAU, cada um vê 50 tweets/dia e posta 2 tweets/dia."
Cálculo canônico:
Decisões arquiteturais que decorrem:
- ~350k reads QPS pico → cache agressivo (Redis/Memcached), tweets em memória, fan-out no write pra timelines de usuário ativo
- ~14k writes QPS pico → fila (Kafka) + workers assíncronos populando feed, não grava sincronamente pros seguidores
- ~0.5 PB/ano → impossível em SQL single-node; Cassandra pra tweet store + S3 pra mídias + Redshift/BigQuery pra analytics
- Hot tweets (Kardashian com 100M followers): fan-out on read, não on write. Senão 100M escritas por 1 post
Os 5 erros mortais em back-of-envelope
- Confundir bit e byte. "10 Gbps" é 10 gigabits/s = 1.25 GB/s. Rede vem em bits; storage em bytes. Confundir = off-by-8.
- Usar média quando importa o pico. "Facebook tem 1B QPS médio" é inútil — pico real é 3-10x maior e define a capacidade.
- Esquecer replicação e índice. Dataset bruto "é 1 TB" — mas com replica 3x + índice ~30% + hot/cold tier, real ≈ 4-5 TB.
- Calcular storage sem considerar compactação. Logs compactados chegam a 10x menores. Parquet + snappy reduz 3-5x textual data.
- Não levar a decisão arquitetural. Número sem conclusão é trivia, não engenharia.
Take-away: números que entrevistador espera que você saiba
Memorize essa tabela. Ela cobre 90% dos cálculos que aparecem em entrevista sênior.
| Grandeza | Valor memorizar | Uso |
|---|---|---|
| Segundos/dia | ~10⁵ (86.4k) | Converter req/s ↔ req/dia |
| RAM read | ~100 ns | Cache hit latência |
| SSD read 4K | ~100 µs | DB sem cache latência |
| Network 1KB mesmo DC | ~250 µs | Service mesh RTT |
| Cross-region RTT | ~100 ms | Disaster recovery design |
| Postgres single-node | ~10k tx/s, ~2TB | Quando partir pra sharding |
| Kafka por broker | ~100 MB/s | Tamanho do cluster de ingestão |
| S3 $/GB/mês | ~$0.023 | Cost vs EBS (~$0.10) / RDS (~$0.30) |
| Redis latência | ~1 ms mesmo DC | Cache layer design |
Back-of-envelope virtuoso em entrevista ≠ memorização bruta. É usar números pra narrar decisões: "Esse volume cabe em X, logo proponho Y". A conta é só a legenda da decisão arquitetural que vem depois.
Perguntas frequentes
❓ Quais números vale memorizar?
❓ Como estimar vazão numa entrevista?
❓ Por que o cálculo convence?
Fixando
Ao estimar armazenamento, qual erro mais distorce o resultado?
Qual referência de latência é mais útil memorizar?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…