1. Estimativas

Às 09:55 o time da BoxOffice está olhando para um dashboard. Em cinco minutos começa a venda de um show em estádio: 2 milhões de fãs para 60 mil lugares. Quantas requisições por segundo vão chegar ao catálogo? Quantas reservas de assento por segundo o banco vai receber? O mapa de assentos cabe em memória? Quantos servidores de aplicação precisamos? As respostas decidem a arquitetura — e dá para obtê-las antes de escrever uma linha de código, com uma folha de papel e algumas fórmulas. É isso que este exercício treina.

Contexto

A estimativa de guardanapo (back-of-the-envelope) é o segundo passo do roteiro de entrevista e a primeira coisa que um revisor procura em um design doc¹. O objetivo é a ordem de grandeza certa, não três algarismos significativos: 12 mil ou 15 mil requisições por segundo levam ao mesmo design; 1,2 mil ou 120 mil, não.

As ferramentas vêm da Aula 2 — Estimativas: potências de dois e de dez, os números de latência e vazão², a Lei de Little, utilização, percentis e matemática de disponibilidade. No Lab 2 você vai conferir alguns desses números em um serviço real.

Fórmulas que você vai usar

Tarefa

Preencha uma planilha de estimativas para cinco sistemas:

1. Venda relâmpago da BoxOffice — obrigatória para todos (fatos abaixo).
2. Quatro sistemas escolhidos entre as fichas abaixo (pelo menos um com muita leitura e um com muita escrita).

Para cada sistema, estime as grandezas do template, mostre as contas e termine com três consequências de design derivadas dos seus números.

Fatos da BoxOffice

• A venda de um show em estádio começa às 10:00; 2 M de fãs chegam nos primeiros 10 minutos; há 60 mil lugares, no máximo 4 por pedido.
• Um fã navegando faz, em média, uma requisição a cada 3 segundos (catálogo, mapa de assentos, consulta de disponibilidade).
• Uma sala de espera admite fãs no fluxo de compra a uma taxa que você deve escolher para que a venda dure cerca de 15 minutos.
• Uma reserva de assento dura 5 minutos; cerca de 30% das reservas expiram sem pagamento.
• Um registro de pedido tem cerca de 1 KB; um e-mail de ingresso, cerca de 50 KB; o mapa de assentos do local, cerca de 200 KB de JSON.
• Fora das vendas, a BoxOffice atende 5 M de usuários ativos por dia, que navegam ~20 páginas cada.

Fichas

Todos os fatos abaixo são premissas ilustrativas para o exercício — use-os como dados e acrescente suas próprias premissas onde for preciso.

Requisitos

• (obrigatório) Cinco planilhas completas: BoxOffice + quatro fichas (pelo menos uma com muita leitura e uma com muita escrita).
• (obrigatório) Todo número tem unidade e todo número derivado mostra sua fórmula (nada de resultados soltos).
• (obrigatório) As premissas estão em uma tabela, separadas dos fatos dados.
• QPS médio e de pico, separados em leituras e escritas.
• Armazenamento por ano (com replicação) e banda (entrada e saída).
• Tamanho do cache para o conjunto quente, e se ele cabe em um nó.
• Número de servidores para o caminho mais quente, usando a Lei de Little para a concorrência e uma utilização-alvo.
• Disponibilidade do caminho principal (série/paralelo) comparada com um SLO-alvo.
• Uma verificação de sanidade por sistema contra um número de referência (por exemplo, do cheat sheet de números).
• Três consequências de design por sistema, cada uma apontando para um número da planilha.
• Seção Uso de IA (veja a política).

Entregáveis

• Uma página estimation no site da sua documentação com as cinco planilhas (tag ex1).
• Opcional: a planilha eletrônica ou o script que você usou (versionado no repositório) — a página ainda precisa mostrar as fórmulas.

Passo a passo

1. Leia os fatos e escreva a pergunta. "Quantas reservas de assento por segundo no pico?" é uma pergunta; "estime a BoxOffice" não é.
2. Liste as premissas antes de calcular. Escreva o que você supõe e por quê (por exemplo, "fator de pico 3, de uma curva diária típica").
3. Calcule as médias, depois os picos. Requisições por dia ÷ 10⁵ dá o QPS médio; multiplique pelo fator de pico. Em eventos (vendas, campanhas), calcule o pico diretamente a partir do evento: usuários × taxa de requisições.
4. Separe leituras e escritas. Elas atingem componentes diferentes (cache/CDN vs banco primário).
5. Dimensione os dados. Itens × tamanho × retenção × replicação. Depois, o conjunto quente para o cache.
6. Dimensione a computação. A Lei de Little dá as requisições em andamento; a capacidade por servidor e uma utilização-alvo dão o número de servidores.
7. Verifique a disponibilidade. Multiplique as disponibilidades ao longo do caminho principal; acrescente réplicas onde o resultado ficar abaixo do SLO.
8. Verifique a sanidade. Compare com algo que você conhece (um número da aula, um blog de engenharia público, o cheat sheet).
9. Escreva as consequências. Cada consequência é uma decisão justificada por um número.

Exemplo resolvido: encurtador de URL

Fatos (ilustrativos): 100 M de URLs curtas novas por mês; proporção leitura/escrita de 100:1; registros mantidos por 5 anos; 500 bytes por registro.

Verificação de sanidade: 2 MB/s de saída é pouquíssimo — uma única placa de rede de 1 Gbit/s move ~125 MB/s. O gargalo não é a banda.

Consequências de design:

1. 12 mil leituras/s vs 120 escritas/s → muita leitura: um cache na frente do banco (uma taxa de acerto acima de 90% elimina a maior parte das leituras no banco).
2. 9 TB em 5 anos → cabe em um cluster SQL, mas um armazenamento chave-valor particionado pela chave curta mantém o crescimento simples; nenhum join é necessário.
3. 99,94% < meta de 99,99% → o banco é o elo mais fraco: acrescente um standby com failover automático (ou aceite o SLO).

Um pequeno ajudante (opcional)

Escrever as contas como código mantém as unidades honestas. Você pode adaptar este script; a página ainda precisa mostrar as fórmulas.

DAY = 86_400  # seconds


def qps(per_day: float, peak_factor: float = 3.0) -> tuple[float, float]:
    """Average and peak requests per second."""
    avg = per_day / DAY
    return avg, avg * peak_factor


def servers(peak_qps: float, per_server: float, target_util: float = 0.7, spare: int = 2) -> int:
    """Instances needed at the target utilization, plus spare capacity (N+spare)."""
    from math import ceil
    return ceil(peak_qps / (per_server * target_util)) + spare


def series(*avail: float) -> float:
    """Availability of components in series."""
    out = 1.0
    for a in avail:
        out *= a
    return out


def parallel(a: float, n: int) -> float:
    """Availability of n independent replicas."""
    return 1 - (1 - a) ** n


if __name__ == "__main__":
    writes = 100e6 / 30          # URL shortener: writes per day
    w_avg, w_peak = qps(writes)
    r_avg, r_peak = w_avg * 100, w_peak * 100
    print(f"writes {w_avg:,.0f}/s avg, {w_peak:,.0f}/s peak")
    print(f"reads  {r_avg:,.0f}/s avg, {r_peak:,.0f}/s peak")
    print(f"in flight at peak: {r_peak * 0.020:,.0f}")
    print(f"app servers: {servers(r_peak, 1_000)}")
    print(f"availability: {series(0.9999, parallel(0.999, 2), 0.9995):.4%}")

Templates

Copie uma planilha por sistema para a sua página.

## System: <name>

### Given facts
| Fact | Value |
|-|-|
| ... | ... |

### Assumptions
| # | Assumption | Value | Why |
|-|-|-|-|
| A1 | Peak factor | 3× | daily curve with an evening peak |
| A2 | Capacity per app instance | 1,000 req/s | measured in Lab 2 / cheat sheet |

### Estimates
| Quantity | Formula | Result | Unit |
|-|-|-|-|
| Reads, average | | | req/s |
| Reads, peak | | | req/s |
| Writes, average | | | req/s |
| Writes, peak | | | req/s |
| Storage per year (with replication) | | | TB |
| Ingress bandwidth | | | MB/s |
| Egress bandwidth | | | MB/s |
| Cache (hot set) | | | GB |
| Concurrency at peak (L = λW) | | | requests |
| Servers for the hottest path | | | instances |
| Availability of the main path | | | % |

### Sanity check
<compare one number with a known reference>

### Design consequences
1. <decision> — because <number from the sheet>
2. ...
3. ...

## Sistema: <nome>

### Fatos dados
| Fato | Valor |
|-|-|
| ... | ... |

### Premissas
| # | Premissa | Valor | Por quê |
|-|-|-|-|
| P1 | Fator de pico | 3× | curva diária com pico à noite |
| P2 | Capacidade por instância da aplicação | 1.000 req/s | medido no Lab 2 / cheat sheet |

### Estimativas
| Grandeza | Fórmula | Resultado | Unidade |
|-|-|-|-|
| Leituras, média | | | req/s |
| Leituras, pico | | | req/s |
| Escritas, média | | | req/s |
| Escritas, pico | | | req/s |
| Armazenamento por ano (com replicação) | | | TB |
| Banda de entrada | | | MB/s |
| Banda de saída | | | MB/s |
| Cache (conjunto quente) | | | GB |
| Concorrência no pico (L = λW) | | | requisições |
| Servidores no caminho mais quente | | | instâncias |
| Disponibilidade do caminho principal | | | % |

### Verificação de sanidade
<compare um número com uma referência conhecida>

### Consequências para o design
1. <decisão> — porque <número da planilha>
2. ...
3. ...

Rubrica

Níveis conforme definidos em Como os exercícios são avaliados.

FAQ