Como você estima escala e faz planejamento de capacidade?

Question

Accepted Answer

**Estimação e planejamento de capacidade** — calcular carga esperada, volume de dados e necessidades de recursos — é uma parte importante do design de sistemas. Cálculos aproximados "de cabeça" informam decisões de design (quanto escalar, quais recursos são necessários) e são comuns em entrevistas de design.

## Por que isso importa

```text
Estimating scale informs DESIGN decisions:
  → how many servers? how much storage? what database? do you need sharding/caching?
  → understanding the SCALE (small vs massive) shapes the whole design
→ rough numbers guide whether/how to scale (don't over- or under-engineer)
```

## O que estimar (de cabeça)

```text
✓ TRAFFIC → users, requests/sec (QPS); read vs write ratio (e.g. 100:1 reads:writes)
  → peak vs average (design for peak); daily active users → requests
✓ STORAGE → data size per item × volume × growth over time → total storage (and growth rate)
✓ BANDWIDTH → data transferred per second (request size × QPS)
✓ MEMORY → cache size needed (e.g. cache the hot 20% of data)
→ rough estimates (order of magnitude) → good enough to inform design
```

## Números úteis e abordagem

```text
→ Know rough "latency numbers": memory ~ns, SSD ~µs, network/disk ~ms, cross-region ~100ms
→ Round numbers; use powers of 10; estimate, don't seek precision
→ Example: 1M daily users × 10 requests = 10M/day ≈ ~115 req/sec average (× peak factor)
→ derive resource needs from the estimates → justify the architecture
→ CAPACITY PLANNING → provision for expected load + growth + headroom; plan to scale
```

## Por que isso importa

Entender como estimar escala e fazer planejamento de capacidade é conhecimento valioso de nível sênior porque **estimação informa decisões de design de sistemas** e é uma parte comum do trabalho de design e entrevistas, então é uma habilidade útil e prática.

Estimar escala — calcular carga esperada, volume de dados e necessidades de recursos por meio de cálculos aproximados "de cabeça" — é importante porque **compreender a escala molda todo o design**: saber se um sistema processa milhares ou bilhões de requisições determina quanto escalar, quais bancos de dados usar, e se sharding e cache são necessários, ajudando a evitar tanto over-engineering (complexidade desnecessária para pequena escala) quanto under-engineering (um design que não consegue lidar com a carga real).

Entender **o que estimar** — **tráfego** (usuários, requisições/seg, razões leitura/escrita, pico vs média), **armazenamento** (tamanho de dados e crescimento), **largura de banda**, e necessidades de **memória/cache** — fornece o framework para dimensionar um sistema.

Entender a **abordagem** — conhecer números de latência aproximados (memória vs SSD vs rede vs entre regiões), usar números redondos e potências de 10, estimar ordem de magnitude em vez de buscar precisão, derivar necessidades de recursos das estimativas para justificar a arquitetura, e **planejamento de capacidade** (provisionar para carga esperada mais crescimento e margem) — reflete a habilidade prática de fazer estimativas úteis rapidamente.

Esta é uma habilidade comum e esperada em entrevistas de design de sistemas (onde estimação de cabeça demonstra que você consegue raciocinar sobre escala) e em planejamento de capacidade real.

Como estimar escala informa decisões-chave de design (como escalar, quais recursos são necessários, evitando over/under-engineering) e é uma parte comum do trabalho e entrevistas de design de sistemas, e como entender o que estimar e como (cálculos de cabeça, números de latência, planejamento de capacidade) é uma habilidade prática, entender como estimar escala e fazer planejamento de capacidade é conhecimento valioso de nível sênior — uma habilidade útil e esperada para design de sistemas que informa decisões arquiteturais por meio de raciocínio quantitativo aproximado, comum tanto em planejamento de capacidade real quanto em entrevistas de design, e refletindo a capacidade de fundamentar designs em estimativas realistas de escala e necessidades de recursos.