Números que Todo Engenheiro Deve Saber

Quanto tempo leva para ler um lugar da memória? De um SSD? De um banco no mesmo data centre? De um servidor na Virgínia, com o fã em São Paulo? As respostas cobrem oito ordens de grandeza — de um nanossegundo a cem milissegundos — e a maioria das regras práticas de arquitetura ("ponha em cache", "agrupe as chamadas", "não chame outra região de forma síncrona") são apenas consequências dessa amplitude. Esta página reúne os números que vale a pena memorizar e mostra como transformá-los, junto com algumas premissas sobre os usuários, em requisições por segundo, armazenamento e banda.

Potências de dois (e de dez)

Tamanhos de dados são potências de dois; estimativas são mais fáceis em potências de dez. Como 2¹⁰ = 1.024 ≈ 10³, você pode alternar livremente entre as duas para estimar:

A rigor, 2¹⁰ bytes é um kibibyte (KiB) e 10³ bytes é um quilobyte (kB); a diferença (2,4% no KB, 10% no TB) não importa para estimativas de guardanapo.

Tempo

Uma tabela de conversão útil, usando 1 dia ≈ 10⁵ s (o fator exato é 86.400, o que torna as taxas reais cerca de 15% maiores):

Números de latência que todo engenheiro deveria saber

Em 2009, Jeff Dean (Google) popularizou uma lista de "números que todos deveriam saber" — o custo de operações básicas num computador e numa rede¹. O hardware mudou desde então (SSDs substituíram discos giratórios no caminho quente, as redes ficaram mais rápidas), mas as proporções se mantiveram notavelmente estáveis, porque alguns limites — a velocidade da luz, a física da memória — não melhoram. A tabela usa ordens de grandeza dos anos 2020, compiladas da lista de Dean, de suas atualizações posteriores² e do Systems Performance de Gregg³; o seu hardware pode diferir por 2–3×, o que não tem problema para estimativas.

O que a tabela ensina

1. A memória é ~1.000× mais rápida que o SSD, e o SSD ~100× mais rápido que o HDD em leituras aleatórias. É por isso que caches (o Redis mantém tudo em RAM) e índices em memória existem.
2. Dentro de um data centre, a rede custa mais que o trabalho. Um GET no Redis consome microssegundos de CPU no servidor; o que você espera é a ida e volta. Uma página que faz 50 chamadas sequenciais ao Redis gasta ~10–25 ms só em idas e voltas — agrupe-as (MGET, pipelining) ou use cache no próprio processo.
3. Entre regiões, a física vence. A luz na fibra óptica viaja a cerca de 200.000 km/s, isto é, ~5 µs por km, então cada 100 km acrescentam cerca de 1 ms de ida e volta antes de qualquer roteador ou servidor tocar no pacote. São Paulo–Virgínia são ~7.500 km em linha reta, então a ida e volta mínima teórica é de ~75 ms; as rotas reais dão ~110–130 ms. Nenhuma tecnologia remove isso: evite chamadas síncronas entre regiões no caminho crítico e atenda os usuários de perto (CDN, implantações regionais).
4. Sequencial ganha de aleatório. Ler 1 MB sequencialmente de um SSD custa mais ou menos o mesmo que algumas leituras aleatórias de 4 KB. Armazenamento estruturado em log, o log append-only do Kafka e o processamento em lote exploram isso.
5. Idas e voltas se somam; a banda raramente limita requisições pequenas. Para uma resposta de API de 2 KB, a latência é dominada pelas idas e voltas (abertura de conexão, TLS, a própria requisição), não pelo tempo de transferência. Reaproveitar conexões (keep-alive, HTTP/2) importa mais que um cano mais largo.

Regras práticas de throughput

A latência diz quanto tempo uma operação leva; o planejamento de capacidade também precisa saber quantas operações por segundo um componente sustenta. Esses valores variam muito mais com hardware, configuração e carga do que as latências, então trate a tabela como premissas iniciais ilustrativas que você precisa substituir por medições (é para isso que serve o laboratório 2):

O padrão a lembrar: leituras são mais baratas que escritas duráveis, memória é mais barata que disco e tudo que precisa gravar em disco ou atravessar a rede para confirmar (escritas duráveis, replicação, consenso) tem um teto mais baixo.

Tamanhos típicos

Dois multiplicadores são fáceis de esquecer: replicação (um banco normalmente mantém 3 cópias; object stores replicam internamente) e índices e overhead (muitas vezes 1,5–2× os dados brutos num banco relacional).

Estimando requisições por segundo (QPS)

QPS (queries per second, usado de forma livre para requisições por segundo) é o ponto de partida de toda estimativa de capacidade:

• Fator de pico: o tráfego não é plano ao longo do dia. Para produtos de consumo, a hora mais movimentada costuma ser 2–3× a média diária; é para esse número que você dimensiona. Para negócios movidos a eventos, o pico é um salto repentino que nada tem a ver com a média diária — estime-o separadamente.
• Proporção leitura/escrita: divida as ações em leituras e escritas. Leituras podem ir para cache e ser replicadas; escritas vão para um primário. Um produto com 100:1 e outro com 1:1 são designs diferentes.

Estimando armazenamento

Estimando banda

Estimando servidores e memória

Quando você sabe a carga de pico e a capacidade por nó, o número de nós sai direto — com folga e redundância:

• Utilização-alvo de 60–75% para serviços sensíveis à latência — a página de filas explica por que rodar perto de 100% destrói o p99.
• Reservas (N+1, N+2): se um nó falhar ou estiver em deploy, os outros precisam absorver sua carga sem passar do joelho.

Para a memória de cache, uma regra prática comum é a regra 80/20: uma pequena fração dos itens recebe a maior parte do tráfego, então guardar em cache o conjunto quente — muitas vezes ~20% dos itens, às vezes bem menos — captura a maioria das leituras.

catalog:
  build: ./services/catalog
  environment:
    DB_HOST: db
    DB_PORT: 5432
    DB_NAME: ${DB_NAME:-boxoffice}
    DB_USER: ${DB_USER:-boxoffice}
    DB_PASSWORD: ${DB_PASSWORD:-boxoffice}
    DB_POOL_SIZE: ${DB_POOL_SIZE:-10}  # HikariCP pool size (lab 2 experiments with it)
  ports:
    - "8082:8082"
  depends_on:
    db:
      condition: service_healthy   # wait until PostgreSQL accepts connections
  deploy:
    resources:
      limits:
        cpus: "1.0"                # one core per replica: makes scaling visible in lab 3
        memory: 768M

Como se conecta

flowchart LR
    P2["potências de dois e de dez<br/>1 dia ≈ 10⁵ s"] --> QPS["QPS: média e pico<br/>o pico estimado à parte"]
    LAT["números de latência<br/>RAM, SSD, rede"] --> CACHE["cachear o conjunto quente<br/>→ Caching"]
    LAT --> RT["contar idas e voltas<br/>→ Protocolos da borda"]
    QPS --> NODES["nós = pico / capacidade × U<br/>+ reservas → Compute"]
    QPS --> BW["banda = QPS × tamanho<br/>→ CDN"]
    SIZES["tamanhos típicos"] --> STO["armazenamento × retenção<br/>× replicação"]
    STO --> SHARD["particionar ou não?<br/>→ Bancos de dados"]
    STO --> OBJ["arquivos e logs volumosos<br/>→ object store"]
    NODES --> KNEE["utilização-alvo<br/>→ Filas"]

Componentes da paleta: app (instâncias = pico / capacidade por nó, mais reservas) · sql (pedidos e assentos ficam abaixo de um terabyte; o teto de escritas duráveis) · cache (o conjunto quente, ~0,6 GB para o catálogo) · cdn (banda das imagens fora da origem) · objstore (PDFs de ingressos, imagens, logs) · kafka (~10 MB/s por partição) · vectordb (~4 KB por embedding). Cenários: monolith, read-heavy-cache, cdn-static, url-shortener. Continua em: Filas, Borda — DNS e CDN, Caching, Bancos de dados — particionamento, Estudo de caso: encurtador de URL, Exercício: estimativa.

Pontos-chave