Visão geral

São 10:00 e o BoxOffice abre a venda de um show de estádio: dois milhões de fãs, sessenta mil lugares. Ao longo do semestre você construiu todas as peças necessárias para sobreviver àquela manhã — uma CDN e um WAF na borda, serviços sem estado atrás de um balanceador de carga, um cache, um banco que nunca vende um lugar duas vezes, uma fila, uma integração de pagamento, observabilidade, um teste de carga que encontrou o joelho da curva. Esta aula junta as peças do jeito que um entrevistador pede: um enunciado de uma frase, uma lousa em branco e 45 minutos.

Os doze estudos de caso abaixo são os problemas clássicos das entrevistas de system design. Não são doze sistemas sem relação: são as mesmas poucas ideias — guardar em cache as leituras quentes, tirar o trabalho lento do caminho crítico, escolher uma chave de partição, tornar as retentativas seguras, proteger o único recurso que não escala — combinadas em proporções diferentes. Estudá-los é como o vocabulário da disciplina vira reflexo.

Roteiro

1. Esta visão geral — como estudar um caso, como usar o playground, os casos num relance e os padrões que se repetem.
2. Encurtador de URLs — geração de IDs, base62, cache de links quentes, analytics fora do caminho crítico.
3. Rate limiter — token bucket e janelas deslizantes, contadores atômicos, fail-open vs. fail-closed.
4. Cache distribuído — hash consistente, despejo, replicação, chaves quentes.
5. Autocompletar de busca — trie com top-k, agregação offline, servir da memória.
6. Sistema de notificações — canais, filas, retentativas, deduplicação, provedores.
7. News feed — fan-out na escrita vs. na leitura, celebridades, cache de timelines, ranqueamento.
8. Chat — WebSockets, roteamento entre gateways, ordem, entrega offline, presença.
9. Corridas por aplicativo — ingestão de localizações, índices geoespaciais, matching sem atribuição dupla.
10. Streaming de vídeo — uploads, pipeline de transcodificação, bitrate adaptativo, economia da CDN.
11. Sistema de pagamentos — idempotência, razão contábil de partidas dobradas, integração com PSP, conciliação.
12. Ingressos — a venda relâmpago do BoxOffice — o caso principal: sala de espera, reservas de lugar, checkout.
13. Assistente de IA — RAG, LLM gateway, agentes com ferramentas, guardrails e avaliações.
14. Quiz — verifique seu entendimento.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

Como estudar um caso

Toda página de caso segue o roteiro de entrevista da aula 1, seção por seção, para você ensaiar a ordem até ela ficar automática. O tempo abaixo é para uma entrevista de 45 minutos; as páginas dos casos usam a mesma numeração.

As dez seções de cada página de caso correspondem a essas etapas: requisitos (1), estimativas (2), API e modelo de dados (3), design de alto nível (4), aprofundamentos (5), gargalos e trade-offs (6), e depois três apoios ao estudo — Experimente no playground, Perguntas de follow-up e uma rubrica de autoavaliação.

Como usar o playground com um caso

Cada caso incorpora o System Design Playground já carregado com seu cenário. O playground é um simulador, não um benchmark: seus números são ilustrativos, mas as formas (onde a fila cresce, quando o p99 se curva, qual componente satura primeiro) são as que você vai ver em sistemas reais e nos laboratórios.

flowchart LR
    p["Preveja<br/>o que quebra primeiro?"] --> r["Rode<br/>perfil load / spike"]
    r --> o["Observe<br/>utilização, p99,<br/>erros, backlog, custo"]
    o --> c["Mude uma coisa<br/>réplicas, cache, fila,<br/>timeout, partição"]
    c --> e["Explique<br/>com os números<br/>da seção 2"]
    e --> p

• Preveja antes de rodar. Escreva qual componente você espera que sature e com que carga. Errar é a parte útil.
• Mude uma coisa de cada vez. Acrescente um cache ou réplicas ou uma fila, nunca os três, para saber qual mudança mexeu na métrica.
• Use os perfis: load para regime permanente, spike para o momento das 10:00 do BoxOffice, stress e breakpoint para achar o joelho, chaos (ou o nível de caos) para derrubar ou deixar lentos componentes e ver os modos de falha.
• Ligue aos números das estimativas. Se a página diz que o cache precisa absorver 95% das leituras, olhe a taxa de acerto; se a Lei de Little diz que há 40 chamadas em andamento, olhe a concorrência da dependência.
• Exporte seu design (JSON) quando gostar dele: é o formato do exercício do playground.

Os casos num relance

Ordem sugerida: dos aquecimentos fáceis ao caso principal. A dificuldade é o nível em que o problema costuma ser pedido; todo caso tem uma versão sênior.

Os ids dos componentes são os da paleta do playground; cada um está descrito no catálogo de componentes.

Padrões que se repetem

Depois de alguns casos você vai notar que os aprofundamentos saem de uma lista curta. Reconhecer o padrão num problema novo é a maior parte do trabalho.

O mapa de conceitos dos estudos de caso

Os doze casos são combinações dos mesmos padrões. O mapa agrupa os casos pelo padrão que compartilham (azul), as aulas que o ensinam e os componentes da paleta que o implementam (verde); a matriz abaixo diz quais aulas cada caso testa — ● um aprofundamento é construído sobre ela, ○ ela faz parte do design, — não é central. Cada página de caso termina com seu próprio diagrama Como se conecta.

flowchart LR
    g1["URL shortener · news feed<br/>autocomplete · video"] --> p1["cache the hot reads<br/>(Caching, Edge)"]:::tech
    g2["notifications · video<br/>news feed · payments"] --> p2["slow work off the critical path<br/>(Messaging, Compute)"]:::tech
    g3["payments · ticketing<br/>chat · ride sharing"] --> p3["safe retries, strong consistency<br/>where it matters (Distributed, Databases)"]:::tech
    g4["chat · ride sharing<br/>ticketing · distributed cache"] --> p4["choose the partition key<br/>(Databases)"]:::tech
    g5["ticketing · rate limiter<br/>AI assistant"] --> p5["protect what cannot scale<br/>(Edge, Reliability)"]:::tech
    p1 --> k1["cache · cdn"]:::comp
    p2 --> k2["queue · kafka · worker"]:::comp
    p3 --> k3["sql · payment"]:::comp
    p4 --> k4["nosql · stream · cache"]:::comp
    p5 --> k5["waf · apigw · queue · llmgw"]:::comp
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

O que quebra em seguida

Nada na disciplina quebra em seguida — o próximo sistema é seu. Dezesseis capítulos transformaram um serviço e um banco num projeto em que cada caixa tem um número que a colocou ali e um preço: a sala de espera porque 33.000 reservas/s encontram ~1.100, o cache porque as páginas de evento são lidas 100× mais do que mudam, o circuit breaker porque o provedor responde em 4 s em vez de 200 ms. Três lugares testam se esse raciocínio virou seu. O projeto em equipe constrói e testa sob carga um sistema ao longo dos seus marcos e o quebra de propósito no game day. As entrevistas simuladas pedem isso em voz alta, em 45 minutos, para um sistema que você não viu. O design doc pede que você o escreva para que outra pessoa possa discordar de um número. Nos três, a pergunta é a mesma que todo capítulo fez: qual número coloca esta caixa aqui, e quanto ela custa?

Relacionados

Aula 1 — roteiro de entrevista · Aula 2 — estimativas · Preparação para entrevistas e seus problemas de prática · Exercício de design doc · Projeto em equipe · Playground.

Referências

As páginas dos casos citam suas próprias fontes; os livros abaixo cobrem a maioria delas¹²³.