Capacity Estimation — números que informam decisões de arquitetura

Em 2011, o Instagram tinha 14 milhões de usuários e rodava em menos de 10 servidores EC2. Em 2012, quando foi adquirido pelo Facebook por 1 bilhão de dólares, tinha 30 milhões de usuários e ainda rodava em menos de 10 servidores. O que permitia isso não era magia — era que cada decisão de arquitetura havia sido calibrada para a escala real, não para a escala imaginária. Cache agressivo onde fazia sentido, banco de dados simples onde o volume não justificava sharding, CDN para o que realmente precisava de CDN. Os fundadores sabiam os números do sistema e tomavam decisões baseadas neles.

Capacity estimation é a prática de derivar números concretos — requisições por segundo, storage por ano, banda de rede por hora — a partir dos requisitos de escala do sistema. O objetivo não é precisão: uma estimativa que erra por 2x ainda é útil para decidir se você precisa de cache ou não, se o banco vai saturar em 6 meses ou 6 anos, se CDN é sobre latência ou sobre capacidade. O objetivo é que os números informem decisões arquiteturais — e que as decisões erradas sejam eliminadas antes de virar código.

Os números de referência que você precisa internalizar

Estimation em tempo real requer que certos números estejam na memória — não em uma tabela que você consulta, mas internalizados ao ponto de poder fazer cálculos mentalmente enquanto conversa sobre arquitetura. Esses são os números que aparecem repetidamente:

Latências de I/O

Operação                              Latência típica
─────────────────────────────────────────────────────
L1 cache (CPU)                        ~1 ns
L2 cache (CPU)                        ~4 ns
RAM (leitura sequencial)              ~100 ns
SSD NVMe (leitura aleatória)          ~100 µs    (100.000 ns)
HDD (seek + leitura)                  ~10 ms     (10.000.000 ns)
Redis (rede intra-DC)                 ~0.5 ms
PostgreSQL query simples (com cache)  ~1–5 ms
PostgreSQL query sem cache            ~10–50 ms
Rede intra datacenter                 ~0.5 ms
Rede inter-região (EUA → Europa)      ~150 ms
Rede intra-região AWS (AZ→AZ)         ~1–2 ms

O que esses números revelam sobre design:

• RAM é 100.000x mais rápida que SSD para leitura aleatória — justifica manter hot data em memória
• Redis é ~10x mais rápido que PostgreSQL para leituras simples por chave — justifica cache para leituras frequentes
• 150ms de latência intercontinental é irredutível por física — justifica CDN edge para conteúdo estático e regiões distribuídas para sistemas globais com SLO de latência < 100ms

Throughput de sistemas comuns

Sistema                               Throughput típico
────────────────────────────────────────────────────────────
Servidor web (Nginx, serving estático)    ~50.000 req/s por core
Servidor de aplicação (Go/Java)           ~5.000–20.000 req/s
Servidor de aplicação (Python/Ruby)       ~500–2.000 req/s
PostgreSQL (writes simples)               ~5.000–10.000 writes/s
PostgreSQL (reads com índice)             ~50.000–100.000 reads/s
PostgreSQL com read replicas (×3)         ~150.000–300.000 reads/s
Redis (operações simples, single thread)  ~100.000 ops/s
Redis Cluster (6 shards)                  ~600.000 ops/s
Kafka (throughput de ingestão)            ~1.000.000 msgs/s por partição
S3 (PUT requests)                         ~3.500 PUT/s por prefix
S3 (GET requests)                         ~5.500 GET/s por prefix

A implicação prática mais importante: PostgreSQL com read replicas aguenta ~300k reads/s. Para a maioria dos sistemas, isso é suficiente sem sharding. A pergunta "precisamos de sharding?" deve ser respondida por estimation, não por instinto.

Tamanhos de objetos típicos

Objeto                              Tamanho típico
────────────────────────────────────────────────────
Tweet (texto + metadados)           ~500 bytes
Registro de usuário                 ~1 KB
Mensagem de chat (texto)            ~200 bytes
Imagem de perfil (JPEG comprimida)  ~100 KB
Post de blog (texto, sem imagens)   ~10 KB
Foto de alta resolução (JPEG)       ~3–5 MB
Vídeo de 1 minuto (1080p, H.264)    ~50–150 MB
Log estruturado por linha           ~500 bytes

O processo de estimation em quatro derivações

A estimation parte sempre de uma âncora — o número de usuários ativos diários (DAU) ou mensais (MAU). Dali, quatro derivações informam as decisões mais importantes de arquitetura:

Derivação 1: QPS (queries per second)

# Fórmula base:
# QPS = DAU × operações_por_usuário_por_dia ÷ 86.400 segundos

# Exemplo: sistema de microblog tipo Twitter
# DAU: 300M usuários
# Comportamento médio: 5 leituras de timeline, 0,1 tweets por usuário/dia
# Razão leitura:escrita = 50:1

QPS_write = 300M × 0,1 tweets ÷ 86.400s
          = 30M ÷ 86.400
          ≈ 347 writes/s
          → pico (3× média): ~1.000 writes/s

QPS_read  = 347 × 50
          ≈ 17.350 reads/s
          → pico: ~52.000 reads/s

# Decisão que essa estimation informa:
# 1.000 writes/s → PostgreSQL aguenta sem sharding
# 52.000 reads/s → PostgreSQL sem cache não aguenta (~50k é o limite)
#                  Redis cache com 95% hit rate → banco recebe 2.600 reads/s ✓

Derivação 2: Storage em N anos

# Fórmula:
# Storage = objetos_criados_por_dia × tamanho_por_objeto × dias × fator_replicação

# Continuando o exemplo do microblog:
# Writes/dia = 1.000/s × 86.400s = ~86M tweets/dia
# Tamanho por tweet: texto(280 chars) + metadados + índices ≈ 500 bytes

Storage_raw_por_dia = 86M × 500 bytes = 43 GB/dia
Storage_raw_5_anos  = 43 GB × 365 × 5 = ~78 TB

# Com replicação 3×: ~234 TB
# Com índices e metadados adicionais (~2×): ~470 TB

# Decisão que essa estimation informa:
# 470 TB em 5 anos com crescimento uniforme → particionamento por data é
# suficiente; sharding por user_id ainda não obrigatório no horizonte de 5 anos.
# Mas se o crescimento for 2× ao ano: 78TB × 2^5 = 2,5 PB → sharding necessário
# antes do ano 3. Vale modelar os dois cenários.

Derivação 3: Bandwidth de rede

# Fórmula:
# Bandwidth = QPS_read × tamanho_médio_resposta

# Sistema de foto (tipo Instagram):
# QPS_read: 100.000 reads/s no pico (feeds de foto)
# Tamanho médio da resposta: thumbnail (50KB) + metadata (1KB) ≈ 51KB
# (foto full-resolution servida pelo CDN, não pelo app server)

Bandwidth_inbound  = 1.000 writes/s × 3MB foto original = 3 GB/s  → S3 direct upload
Bandwidth_outbound = 100.000 reads/s × 51KB             = 5,1 TB/s

# 5,1 TB/s de outbound é impossível de servir da origem.
# → CDN não é opcional. É a diferença entre "funciona" e "não funciona".
# → Mesmo com 99% de cache hit no CDN, a origem recebe 51 GB/s — ainda precisa
#   de múltiplas regiões e object storage distribuído (S3 com multi-region).

# Decisão que essa estimation informa:
# CDN é infraestrutura crítica, não otimização. S3 direct upload com
# CloudFront (ou equivalente) não é uma escolha — é requisito.

Derivação 4: Memória de cache necessária

# Princípio de Pareto: 80% do tráfego acessa 20% dos dados
# Se você cacheia o "top 20%", atende ~80% das leituras sem ir ao banco

# Microblog: 86M tweets/dia, os 20% mais acessados são ~17M tweets
# Tamanho por tweet em cache: 500 bytes (só o hot path, sem índices)
# Memória necessária: 17M × 500 bytes = 8,5 GB

# Redis node com 32GB de RAM → cabe com folga
# Redis Cluster não necessário nessa escala → single node com sentinel para HA

# Decisão que essa estimation informa:
# Cache fit em memória de um único nó → Redis single node com AOF
# é suficiente. Kafka não é necessário para invalidação de cache nessa escala.

Como estimation muda o design: dois exemplos contrastantes

A mesma categoria de sistema com escalas diferentes requer arquiteturas radicalmente diferentes. Isso ilustra por que estimation precede o design — não o contrário.

Sistema de URL shortener: 1k vs 100k redirects/segundo

Cenário A: startup pequena, 1k redirects/s
─────────────────────────────────────────
QPS_read:  1.000 redirects/s
QPS_write: 10 URLs/s (razão 100:1)
Storage:   10 writes/s × 200B × 86400s × 365 dias × 5 anos = ~316 GB

Arquitetura:
  - 1 servidor de aplicação (Go)         → aguenta 1k req/s com folga
  - 1 PostgreSQL primary + 1 read replica → aguenta 1k reads/s sem cache
  - Redis opcional                        → adiciona se latência P99 for problema
  - Sem CDN (latência não é requisito)    → origem aguenta o volume

Cenário B: escala real (bit.ly, tinyurl), 100k redirects/s
───────────────────────────────────────────────────────────
QPS_read:  100.000 redirects/s
QPS_write: 1.000 URLs/s
Storage:   1000 writes/s × 200B × 86400s × 365 × 5 anos = ~31.5 TB

Arquitetura:
  - 5–10 servidores de aplicação (load balanced)
  - Redis Cluster para cache de redirects (99% hit rate → banco recebe 1k/s)
  - PostgreSQL com 3 read replicas → banco recebe 1k reads/s (com 99% cache hit)
  - CDN global (latência P99 < 50ms em qualquer região)
  - Particionamento de analytics por data (analytics > redirect data em volume)
  - Geração de short code: precisa de coordination para evitar colisões (ver C03)

A diferença não é "otimizar" o Cenário A para virar o Cenário B — são soluções fundamentalmente diferentes para o mesmo problema em escalas diferentes. Construir o Cenário B para o Cenário A é over-engineering com custo real de complexidade e operação.

Erros comuns em estimation

Confundir média com pico: a maioria do tráfego web tem picos de 5–10x a média. Um sistema dimensionado para a média vai cair durante pico. A regra prática: dimensionar para 3× a média como steady state, com autoscaling para absorver picos de até 10×. Um banco de dados dimensionado para a média com headroom de 30% vai saturar na primeira Black Friday.

Ignorar replicação no cálculo de storage: 1 TB de dados brutos com replicação fator 3 e índices que tipicamente adicionam 30–50% ao tamanho resulta em ~4 TB de storage real. Storage de produção geralmente é 3–5× o tamanho dos dados brutos quando você inclui replicação, índices, logs de replicação, e backups.

Não separar leitura de escrita: leitura e escrita têm características de carga completamente diferentes. Um sistema read-heavy (razão 100:1) tem solução diferente de um sistema write-heavy (razão 1:10) mesmo com o mesmo número total de operações. PostgreSQL com read replicas escala leitura horizontalmente mas não escrita — se o gargalo é escrita, read replicas não ajudam.

Esquecer de onde vêm os bytes: a banda de rede do sistema de fotos não é determinada pelo número de uploads (inbound) — é determinada pelo número de downloads (outbound), que pode ser 100x maior. Sistemas de mídia têm assimetria radical entre inbound e outbound que muda completamente a estratégia de infraestrutura.

Assumir que crescimento é linear: storage cresce linearmente com o tempo (dados acumulam), mas QPS pode crescer exponencialmente em lançamentos virais. O capacity plan precisa modelar os dois cenários: crescimento orgânico esperado e crescimento explosivo não-esperado (o que acontece se você aparecer no ProductHunt amanhã?).

Da estimation à decisão arquitetural

Estimation só tem valor se informa decisões. A conexão explícita entre número e decisão é o que separa estimation útil de exercício matemático:

Número derivado               → Decisão arquitetural

QPS_read > 50k               → Cache obrigatório (Redis na frente do banco)
QPS_read > 300k              → Read replicas + cache + considerar sharding
QPS_write > 10k              → Sharding ou banco NoSQL para writes
Storage > 10 TB em 5 anos    → Particionamento por data desde o início
Storage > 100 TB em 5 anos   → Sharding, tiered storage (hot/warm/cold)
Bandwidth_out > 10 GB/s      → CDN obrigatório
Objetos > 1 MB               → Object storage (S3), nunca blob em banco relacional
Latência P99 < 50ms global   → CDN edge + regiões distribuídas
DAU > 10M                    → Considerar separação de banco por domínio
Mensagens > 100k/s           → Kafka; abaixo disso SQS/RabbitMQ é suficiente

Esses thresholds não são regras absolutas — são pontos de inflexão onde as alternativas mais simples deixam de ser viáveis. Abaixo de 50k reads/s, PostgreSQL com boas queries e índices geralmente aguenta sem cache. Acima disso, a probabilidade de precisar de cache cresce rapidamente.

Estimation como ferramenta contínua, não ritual de design

Estimation não é só para novos sistemas. Em sistemas existentes, estimation retroativa revela problemas antes que se tornem crises:

• Crescimento de storage: se o banco cresce 50 GB/mês e o disco primário tem 2 TB, você tem ~3 meses antes de saturar — não 3 anos. Essa conta simples, feita regularmente, previne o incidente de disco cheio que derruba produção.
• Aproximação do limite de conexões: PostgreSQL tem um limite de conexões simultâneas (geralmente 100–200 em instâncias menores). Se cada deploy adiciona 2 conexões e você faz 3 deploys por semana, em quanto tempo você chega no limite? Essa conta revela quando connection pooling (PgBouncer) precisa ser introduzido — antes do problema, não durante.
• Cache hit rate declinante: se o cache tem 95% de hit rate com 1M usuários ativos mas apenas 10% dos dados cabe em memória, o hit rate vai cair à medida que a base de usuários cresce e o conjunto de dados quentes se expande. Modelar como o hit rate evolui com o crescimento permite planejar quando aumentar a capacidade de cache ou mudar a estratégia de caching.

Decisões de engenharia

Perguntas de entrevista

Exercícios práticos