Preparação para entrevistas System Design 2027.1

Entrevistas de System Design

Como pensar, estimar, desenhar e defender um sistema escalável em voz alta, em 45 minutos. Um mapa do que as entrevistas de system design perguntam, um framework para ensaiar, uma tabela de diagnóstico rápido, os conceitos-chave com link para a aula em que cada um é ensinado, um quiz, um plano de estudo de duas semanas e um checklist para acompanhar seu progresso. Todos os exemplos usam o BoxOffice, a plataforma de ingressos que construímos no curso.

A pergunta das 10h

Uma cena que vai acontecer com você.

Terça-feira, 10h. A última etapa do processo de estágio que você mais queria, numa empresa que vende ingressos online. Desta vez sem código: um quadro compartilhado, uma engenheira do time de plataforma e 45 minutos. Depois das apresentações, ela escreve uma única linha no quadro:

"Projete um site de ingressos para um show num estádio. A venda abre sábado às 10:00."
É tudo o que ela diz. Ela quer ver como você pensa.

Existe uma resposta fraca: pegar a caneta e desenhar, em silêncio, as caixas de sempre (um load balancer, três servidores, um cache, um banco) e dizer "escala". E existe uma forte, que começa com perguntas de volta: "Quantos assentos, e quantos fãs esperamos às 10:00? Podemos, em algum caso, vender o mesmo assento duas vezes? Por quanto tempo um fã pode segurar um assento enquanto paga?" Com as respostas (digamos 60.000 assentos e 2 milhões de fãs), o problema muda de forma. Servir 2 milhões de cópias da página do evento é a parte fácil: é para isso que existe uma CDN (rede de distribuição de conteúdo). A parte difícil é que 2 milhões de pessoas disputam 60.000 linhas de um banco de dados no mesmo minuto, e que nenhuma dessas linhas pode ser vendida duas vezes.

A diferença entre as duas respostas não é ter decorado mais caixas. É saber conectar o que você aprendeu: requisitos e estimativas, onde está a disputa, o que precisa de consistência forte e o que pode ser eventualmente consistente, como uma fila transforma um pico numa fila organizada, e o que quebra primeiro. Esta página mostra esse caminho. No final, voltamos à pergunta das 10h com a resposta completa.

Como é uma entrevista de system design

Quatro tipos de pergunta, uma habilidade: raciocinar sobre um sistema em voz alta, com números e trade-offs.

Design aberto

"Projete um encurtador de URLs"

A clássica pergunta de 45 minutos. Não há resposta única: há requisitos que você esclarece, números que você estima, um design que você justifica e trade-offs que você nomeia. O entrevistador conduz você para um ou dois aprofundamentos.

Aprofundamento num componente

"Torne este rate limiter distribuído"

Uma caixa do design, em profundidade: o algoritmo (token bucket, janela deslizante), onde fica o estado, o que acontece quando esse estado fica indisponível. Testa se você conhece o componente além do nome.

Diagnóstico

"O p99 triplicou depois do deploy"

Um sintoma e um pedido de diagnóstico. Testa se você lê métricas, traces e logs, e se conhece os suspeitos de sempre: saturação, uma dependência lenta, cache frio, retries, um lock.

Estimativa

"Quantos servidores precisamos?"

Contas de guardanapo: usuários para requisições por segundo, fator de pico, armazenamento por ano, banda, Lei de Little. O que importa é a ordem de grandeza, e dizer as suposições em voz alta importa mais ainda.

O que separa os candidatos

Para um estágio ou primeiro emprego, ninguém espera que você já tenha operado um sistema com milhões de usuários. O que derruba candidatos são as armadilhas básicas: desenhar antes de perguntar, projetar sem um único número, citar tecnologias sem dizer por quê ("eu usaria Kafka"), ignorar o que acontece quando algo falha, e ficar em silêncio. Evite essas cinco e você já está à frente da maioria.

O que o entrevistador avalia

Delimitar o problema Estimativas realistas Um design de alto nível sólido Profundidade técnica Trade-offs e gargalos Comunicação e condução

Dimensão	Sinal forte	Sinal de alerta
Requisitos	Separa requisitos funcionais de não funcionais; pergunta sobre escala, consistência e latência antes de desenhar	Começa a desenhar no primeiro minuto
Estimativa	Transforma usuários em requisições por segundo e gigabytes, com o pico, e usa os números para decidir	Números que nunca influenciam uma decisão, ou nenhum número
Design de alto nível	Um design simples que cobre todos os requisitos, com fluxo de dados claro	Vinte caixas sem explicação do que circula entre elas
Profundidade	Aprofunda onde o problema é difícil (no BoxOffice: a disputa por assentos)	Aprofunda onde é fácil (escolher um framework de frontend)
Trade-offs	"X em vez de Y porque… o custo é… eu revisaria se…"	"X é o melhor", "escala"
Falhas	Pergunta o que acontece quando cada caixa falha; timeouts, retries, idempotência	Um design que só funciona quando tudo funciona
Comunicação	Pensa em voz alta, confere com o entrevistador, conduz o próximo passo	Silêncios longos, ou espera que digam o que fazer

Nível	O que se espera	Onde praticar
Estágio / recém-formado	Um design correto e simples; vocabulário claro; estimativas honestas; reage bem a dicas	Problemas de aquecimento e a referência rápida
Pleno	Conduz a sessão inteira; um ou dois aprofundamentos sólidos; nomeia modos de falha sem que peçam	Problemas médios e entrevistas simuladas
Sênior	Encontra rápido a parte difícil, quantifica trade-offs, discute operação, custo e evolução	Problemas difíceis e avançados

Como responder

8 princípios para transformar o que você sabe num design que convence.

1

Esclareça antes de desenhar Quem usa, para quê, quantos, com que rapidez, e o que nunca pode dar errado? Dois minutos de perguntas economizam vinte de redesenho. Uma pergunta bem colocada ("podemos vender o mesmo assento duas vezes?") mostra mais maturidade que qualquer diagrama. Aula 1 · Requisitos →

2

Diga suas suposições, com números "Vou supor 10 milhões de usuários ativos por dia, 20 requisições cada, pico de 3× a média: cerca de 7.000 requisições por segundo no pico." O entrevistador pode corrigir você; o silêncio, não. Arredonde sem medo: um dia tem cerca de 10⁵ segundos. Aula 2 · Estimativas →

3

Primeiro amplo, depois fundo Primeiro um design que cubra todos os requisitos de ponta a ponta, mesmo que ingênuo; só depois os aprofundamentos. Polir o cache antes de o caminho de escrita existir é o jeito mais comum de ficar sem tempo.

4

Desenhe e narre Caixas com nome, setas com o que passa por elas ("POST /holds", "evento OrderPlaced"). Narre uma requisição percorrendo o diagrama. Ensaie com o playground: mesma paleta, mesmo vocabulário.

5

Nomeie o trade-off Toda escolha custa algo. "Vou usar um Redis com cache-aside para o catálogo: as leituras caem de 20 ms para 1 ms e o banco perde 95% da carga, ao custo de até 60 s de preços desatualizados, o que é aceitável para um catálogo, mas não para a disponibilidade de assentos."

6

Encontre o gargalo com números Qual caixa chega primeiro ao limite? Compare a carga estimada com a capacidade de cada componente (números de referência). Utilização acima de uns 70–80% é onde a latência explode: é o joelho da curva de filas. Aula 2 · Filas →

7

Projete para a falha Para cada seta, pergunte: e se ficar lenta? e se falhar? e se a requisição chegar duas vezes? Timeouts, retries com backoff e jitter, circuit breakers, chaves de idempotência e uma dead-letter queue são as respostas padrão. Aula 10 · Padrões de resiliência →

8

Conduza, e confira Você lidera a sessão. Proponha o próximo passo ("a parte difícil é a disputa por assentos, posso aprofundar ali?") e confira com o entrevistador a cada poucos minutos. Se ele levantar uma preocupação, leve a sério: "bom ponto, deixa eu rever isso".

Dica prática: deixe as transições explícitas. "Isso cobre os requisitos; agora uma estimativa rápida." "Temos o design de alto nível; a parte arriscada é o pico das 10:00, vou aprofundar ali." O entrevistador sempre sabe onde você está, e você também.

O framework, passo a passo

Sete passos e um relógio para uma entrevista de 45 minutos. A página do framework tem modelos para cada passo e o BoxOffice resolvido de ponta a ponta.

1

Esclareça os requisitos · ~5 min Requisitos funcionais (as 3–5 funcionalidades centrais, e o que fica fora do escopo) e não funcionais: escala, latência, disponibilidade, consistência, durabilidade, custo. Termine com uma lista curta escrita no quadro. Aula 1 →

2

Estime · ~5 min Requisições por segundo (média e pico), proporção leitura/escrita, armazenamento por ano, banda, e o número que decide o design (no BoxOffice: 2 M de fãs para 60 mil assentos). Aula 2 · Números →

3

API e modelo de dados · ~5 min Os principais endpoints ou eventos (com chaves de idempotência onde há dinheiro ou estoque) e as entidades centrais com suas chaves e padrões de acesso. Os padrões de acesso escolhem o banco. Aula 5 · Estilos de API →

4

Design de alto nível · ~10 min Clientes → borda (DNS, CDN, load balancer, API gateway) → serviços → armazenamento, com o trabalho assíncrono atrás de filas. Percorra uma leitura e uma escrita. Mantenha simples o bastante para caber no quadro. Aula 1 · Jornada de escala →

5

Aprofundamentos · ~12 min Um ou dois componentes onde o problema é difícil: a reserva de assento (transações e locks), o fan-out do feed, a partição quente, a invalidação de cache. É aqui que a profundidade é avaliada. Aula 16 · Estudos de caso →

6

Gargalos e trade-offs · ~5 min O que quebra primeiro com 10× a carga? Onde estão os pontos únicos de falha? O que você trocou (consistência por latência, custo por disponibilidade)? Como você observaria e testaria? Aula 15 · Gargalos →

7

Fechamento · ~3 min Resuma o design em quatro frases, retome os trade-offs principais e liste o que faria a seguir com mais tempo (multi-região, custo, observabilidade, abuso). Deixe o entrevistador com uma imagem clara.

As duas perguntas de escopo que mudam tudo

Sempre pergunte: "Isto é dominado por leituras ou por escritas?" e "O que nunca pode estar errado?" Um sistema de muitas leituras (catálogo, feed, redirecionamento de URLs) se resolve com caches, réplicas e CDN. Um de muitas escritas (atualizações de localização, métricas, cliques) se resolve com particionamento, filas e armazenamento append-only. E o que nunca pode estar errado (um assento, um saldo, um pagamento) é onde você paga por consistência forte, transações e idempotência, enquanto todo o resto pode ser eventualmente consistente.

Diagnóstico rápido

Os sintomas que aparecem em perguntas de diagnóstico e de aprofundamento, o que costumam indicar e o que fazer em seguida.

Numa pergunta de diagnóstico, o entrevistador descreve um sintoma e espera uma hipótese, um jeito de confirmá-la e uma correção. Antes de propor uma arquitetura nova, descarte as causas baratas: um deploy recente, um recurso saturado, uma dependência lenta, cache frio, retries.

Sintoma	Causa provável	Próximo passo
p99 alto, mas CPU ociosa	Threads ou conexões esgotadas esperando uma dependência lenta (Lei de Little: concorrência = taxa × tempo)	Rastrear uma requisição lenta; adicionar timeout e circuit breaker; isolar a chamada lenta (bulkhead); dimensionar o pool
p99 sobe muito com o tráfego, p50 quase plano	Utilização além do joelho (~70–80%): atraso de fila	Escalar ou descartar carga antes do joelho; autoscaling por utilização; achar o recurso saturado (método USE)
Pico de latência logo após um deploy ou restart	Cache frio, JIT frio, pools de conexão se enchendo	Aquecer antes de receber tráfego (readiness probe), liberar aos poucos (canary), pré-aquecer o cache
CPU do banco em 100%, quase tudo leitura	Falta de cache ou de índice; consultas N+1	`EXPLAIN` nas consultas principais; criar índice; cache-aside; réplicas de leitura
O banco derrete no instante em que uma chave popular expira	Cache stampede (thundering herd)	Coalescência de requisições / single flight, lock por chave, renovação antecipada probabilística, TTLs escalonados
Um shard ou partição quente, os outros ociosos	Chave quente ou chave de partição ruim (celebridade, evento em venda relâmpago)	Chave melhor (sufixo / salt), dividir a chave quente, cacheá-la ou dar-lhe um caminho dedicado
Uma falha piora quando a dependência volta	Retry storm: retries sem backoff multiplicam a carga	Backoff exponencial com jitter, orçamento de retries, circuit breaker, endpoints idempotentes
Lag do consumidor crescendo sem parar	Consumidores mais lentos que produtores, ou menos partições que consumidores	Escalar consumidores até o número de partições; adicionar partições; processar em lote; achar o handler lento; DLQ para mensagens venenosas
Usuários veem dados antigos logo depois de salvar	Leitura de réplica atrasada ou cache não invalidado	Read-your-writes: ler do líder após uma escrita, ou invalidar / versionar a entrada de cache
O mesmo pedido cobrado duas vezes	Retry após timeout sem idempotência	Chave de idempotência guardada com o resultado; restrição de unicidade; conciliação com o provedor
Dois fãs ficaram com o mesmo assento	Corrida verifica-depois-age sem lock nem restrição	`SELECT … FOR UPDATE`, um update condicional (`WHERE status = 'free'`) ou uma restrição de unicidade em (evento, assento)
Erros só numa zona de disponibilidade ou região	Falha zonal, host ruim, partição de rede	Health checks e detecção de outliers; drenar a zona; multi-AZ por padrão
A memória cresce devagar até o pod reiniciar	Vazamento; cache ou fila sem limite	Teste de soak; perfil de heap; limitar todo cache e toda fila
O assistente com LLM é lento e caro	Passos de agente demais, sem cache, prompts grandes	Menos passos, cache semântico, modelo menor para roteamento, streaming para o tempo até o primeiro token (TTFT)

Um exemplo completo

"O p99 está em 4 s, a CPU em 15%"

Pergunte: desde quando? depois de um deploy? todos os endpoints ou um só? o que o serviço chama?

Hipótese: uma chamada a jusante ficou lenta; cada requisição agora segura uma thread por segundos, o pool de 200 threads lotou e as novas requisições esperam na fila. Lei de Little: 100 req/s × 2 s = 200 requisições em andamento.

Confirme: um trace mostra 3,8 s dentro da chamada ao provedor de pagamento; as métricas do pool mostram 200/200 ocupadas.

Corrija, do mais barato ao mais caro: timeout de 500 ms, circuit breaker com fallback ("pagamento pendente"), pool separado para essa dependência (bulkhead); depois, tornar o pagamento assíncrono.

Ferramentas por sintoma

O que usar quando

Dashboard RED (taxa, erros, duração): o serviço está saudável para os usuários?

Método USE (utilização, saturação, erros): qual recurso é o gargalo?

Trace distribuído: onde uma requisição lenta gasta seu tempo?

Logs: o que exatamente aconteceu com esta requisição?

Profiler / flame graph: para onde vai a CPU?

EXPLAIN: por que esta consulta é lenta?

Teste de carga (k6) e injeção de falhas (Toxiproxy): reproduza antes de corrigir. Aula 9 →

Os conceitos-chave

Os conceitos que mais aparecem, em dez temas. Tente responder em voz alta antes de abrir cada tema; cada resposta termina com a aula em que o assunto é ensinado. Para cada componente da paleta há uma entrada completa no catálogo de componentes.

[1] Requisitos funcionais vs não funcionais?Funcionais: o que o sistema faz (comprar um ingresso, buscar eventos). Não funcionais: quão bem (latência, disponibilidade, consistência, durabilidade, escala, custo, segurança). Os não funcionais é que definem a arquitetura. Aula 1
[2] Escala vertical vs horizontal?Vertical: uma máquina maior (simples, tem teto, ponto único de falha). Horizontal: mais máquinas atrás de um load balancer (exige serviços sem estado, com o estado compartilhado em outro lugar). Comece vertical, projete para horizontal. Aula 1
[3] Como ir de usuários a requisições por segundo?Usuários ativos por dia × requisições por usuário ÷ 86.400 s (≈ 10⁵), vezes um fator de pico (2–10×; numa venda relâmpago, muito mais). 10 M DAU × 20 ÷ 10⁵ ≈ 2.000 req/s em média. Aula 2
[4] O que é a Lei de Little?L = λ × W: itens no sistema = taxa de chegada × tempo no sistema. 1.000 req/s × 0,2 s = 200 requisições em andamento, então você precisa de umas 200 threads ou conexões. Aula 2
[5] Por que a latência explode perto de 100% de utilização?Filas: numa fila M/M/1, o tempo no sistema é S / (1 − ρ). Com ρ = 0,5 ele dobra o tempo de serviço; com 0,9, multiplica por dez. Mantenha a utilização abaixo do joelho (~70–80%). Aula 2
[6] Por que olhar o p99 e não a média?A média esconde a cauda, e a cauda é o que o usuário sente. Com fan-out, a cauda domina: uma página que chama 100 serviços, cada um lento 1% das vezes, é lenta 1 − 0,99¹⁰⁰ ≈ 63% das vezes. Aula 2
[7] Como as disponibilidades se combinam?Em série se multiplicam (99,9% × 99,9% ≈ 99,8%); em paralelo, multiplicam-se as indisponibilidades (1 − 0,01² = 99,99%). 99,9% ≈ 8,8 h fora do ar por ano; 99,99% ≈ 53 min. Aula 2

Nas aulas: 1 · O que é system design · 2 · Estimativas e fundamentos de desempenho

[8] O que o CAP diz de fato?Durante uma partição de rede, um sistema replicado precisa escolher entre consistência (recusar ou atrasar) e disponibilidade (responder, talvez com dado antigo). Sem partição não há escolha a fazer, e por isso o PACELC acrescenta: senão, latência vs consistência. Aula 3
[9] Consistência forte vs eventual?Linearizável: toda leitura vê a última escrita, como se houvesse uma só cópia. Eventual: as réplicas convergem se as escritas pararem. No meio: read-your-writes, leituras monotônicas, causal. Escolha por dado: assentos fortes, contador de visualizações eventual. Aula 3
[10] O que é um quórum?Com N réplicas, escrever em W e ler de R com R + W > N garante que a leitura cruze a última escrita. N = 3, W = 2, R = 2 é a escolha usual. Aula 3
[11] O que o consenso (Raft) oferece?Um grupo de nós concordando com um log ordenado apesar de falhas, desde que a maioria esteja de pé: eleição de líder, configuração replicada, locks. etcd, ZooKeeper e o KRaft do Kafka usam isso. Precisa de 2f + 1 nós para tolerar f falhas. Aula 3
[12] Por que não confiar no relógio de parede?Relógios derivam e as correções do NTP dão saltos; duas máquinas podem discordar em milissegundos ou mais. Use relógios lógicos (Lamport, vetoriais) para ordenar, ou relógios lógicos híbridos; nunca "a última escrita vence" pelo relógio de parede quando há dinheiro. Aula 3
[13] O que é idempotência e por que importa?Executar uma operação duas vezes tem o mesmo efeito que uma. A rede força retries, e retries duplicam requisições; uma chave de idempotência (guardada com o resultado) torna "cobrar" e "reservar assento" seguros para repetir. Aula 3
[14] Cite falácias da computação distribuída.A rede é confiável; a latência é zero; a banda é infinita; a rede é segura; a topologia não muda; há um único administrador; o custo de transporte é zero; a rede é homogênea. Cada uma é um modo de falha para o qual projetar. Aula 3

Nas aulas: 3 · Fundamentos de sistemas distribuídos

[15] O que uma CDN faz, e o que ela não faz?Serve conteúdo cacheável (imagens, JS, páginas de eventos) a partir de pontos próximos dos usuários, cortando latência e carga na origem. Não consegue cachear dados personalizados ou que exigem consistência forte, como a disponibilidade de assentos às 10:00. Aula 4
[16] Balanceamento L4 vs L7?L4 encaminha conexões TCP/UDP por endereço e porta (rápido, agnóstico ao protocolo). L7 entende HTTP: roteia por caminho ou cabeçalho, termina TLS, faz retries e canaries. A maioria das APIs web usa L7. Aula 4
[17] Por que hashing consistente?Com hash(chave) mod N, mudar N move quase todas as chaves; num anel de hash só cerca de 1/N das chaves se move. Nós virtuais equilibram a carga. Usado em caches, bancos particionados e balanceamento com afinidade. Aula 4
[18] Token bucket vs janela deslizante?Token bucket: fichas recarregam na taxa r até a rajada b; permite rajadas, barato de guardar. Janela deslizante: conta as requisições dos últimos T segundos; mais suave, um pouco mais de estado. Em ambos, o estado fica num armazenamento compartilhado (Redis) e a resposta é 429 com Retry-After. Aula 4
[19] O que faz um API gateway?Um ponto de entrada único: roteamento, autenticação, rate limiting, ajuste de requisições, TLS, observabilidade. Mantenha a lógica de negócio fora dele; um BFF (backend for frontend) é um gateway feito sob medida para um cliente. Aula 4
[20] WebSockets, SSE ou polling?WebSockets: bidirecional, de longa duração (chat, jogos). Server-Sent Events: fluxo do servidor para o cliente sobre HTTP (placar ao vivo, tokens de LLM). Long polling: o plano B. Cada conexão longa custa memória num servidor e complica o balanceamento. Aula 4

Nas aulas: 4 · Tráfego e borda · Catálogo: componentes de borda

[21] Por que servidores de aplicação sem estado?Qualquer réplica atende qualquer requisição, então dá para adicionar, remover e trocar réplicas livremente. Sessão e estado vão para um armazenamento compartilhado (Redis, banco) ou para dentro de um token. Aula 5
[22] Monolito ou microsserviços?Comece com um monolito (modular); extraia um serviço quando um time, um perfil de escala ou um domínio de falha justificar. Microsserviços compram deploys independentes ao preço de chamadas de rede, dados distribuídos e custo operacional. Aula 5
[23] REST, gRPC ou GraphQL?REST: simples, cacheável, APIs públicas. gRPC: binário, tipado, com streaming, entre serviços. GraphQL: o cliente escolhe os campos, bom para frontends variados, mais difícil de cachear e de limitar. Aula 5
[24] Quando mover trabalho para um worker em segundo plano?Quando o usuário não precisa do resultado para continuar (e-mails, miniaturas, relatórios) ou quando o trabalho é lento ou em rajadas. Responda 202 Accepted, enfileire e deixe os workers drenarem a fila no seu ritmo. Aula 5
[25] Quando serverless é uma boa escolha?Tráfego baixo ou em rajadas, orientado a eventos, com tarefas curtas: paga-se por invocação e escala até zero. Atenção a cold starts, limites de concorrência e de tempo, e a avalanches de conexões no banco. Aula 5
[26] Como integrar com segurança a um provedor de pagamento?Chave de idempotência em toda cobrança, timeouts e retries com backoff, webhooks para o status final (verificados e deduplicados) e um job diário de conciliação contra o relatório do provedor. Aula 5

Nas aulas: 5 · Computação e serviços · Catálogo: computação, externos

[27] SQL ou NoSQL?Comece pelos padrões de acesso. Relações, transações e consultas ad hoc: SQL. Escala enorme com acesso simples por chave, esquema flexível ou linhas largas: chave-valor, documentos ou colunas largas. "NoSQL escala, SQL não" é um mito a evitar. Aula 6
[28] Quanto custa um índice?Leituras mais rápidas nas colunas indexadas; escritas mais lentas (cada insert atualiza todos os índices) e mais armazenamento. Indexe para as consultas que você realmente faz; confira com EXPLAIN. Aula 6
[29] B-tree vs LSM-tree?B-tree (PostgreSQL, MySQL): atualização no lugar, leituras rápidas. LSM (Cassandra, RocksDB): acrescenta e compacta, escritas muito rápidas, leituras podem consultar vários arquivos. Cargas de muita escrita favorecem LSM. Aula 6
[30] Como evitar venda dupla?Faça o banco garantir: uma transação com SELECT … FOR UPDATE no assento, ou um update condicional atômico (UPDATE seats SET status='held' WHERE id=? AND status='free'), ou uma restrição de unicidade. Lock otimista (coluna de versão) quando os conflitos são raros. Aula 6
[31] Níveis de isolamento, uma frase cada?Read committed: sem leituras sujas. Repeatable read / snapshot: um retrato consistente, mas write skew é possível. Serializable: como se as transações rodassem uma por vez, ao custo de vazão e abortos. Aula 6
[32] O que uma réplica de leitura oferece, e quanto custa?Mais capacidade de leitura e um standby para failover. O custo é o atraso de replicação: uma leitura logo após uma escrita pode não vê-la. Escritas não escalam com réplicas. Aula 6
[33] Como escolher uma chave de partição?Alta cardinalidade, distribuição uniforme e alinhada com a consulta principal, para a maioria das consultas cair num só shard. Hash para espalhar, intervalo para varreduras por faixa. Atenção a chaves quentes e ao reparticionamento. Aula 6
[34] OLTP vs OLAP?OLTP: muitas transações pequenas sobre dados atuais (pedidos). OLAP: grandes varreduras e agregações sobre o histórico (vendas por artista por mês), num data warehouse colunar alimentado por ETL/ELT ou captura de mudanças (CDC). Aula 6

Nas aulas: 6 · Bancos de dados e sistemas de dados · Catálogo: componentes de armazenamento

[35] Cache-aside, read-through, write-through, write-behind?Cache-aside: a aplicação lê o cache e, numa falta, lê o banco e preenche o cache (o padrão). Read-through: o cache faz isso por você. Write-through: grava no cache e no banco juntos. Write-behind: grava no cache e descarrega depois (rápido, com risco de perda). Aula 7
[36] Como a taxa de acerto vira carga no banco?Carga no banco = requisições × (1 − taxa de acerto). Ir de 90% para 99% de acertos corta as leituras no banco em 10×. Latência média ≈ h × t_cache + (1 − h) × t_banco. Aula 7
[37] Como invalidar?TTL (simples, defasagem limitada), apagar na escrita (cache-aside), eventos / CDC para expulsar, ou chaves versionadas. "Só há duas coisas difíceis…": decida quão desatualizado cada item pode ficar. Aula 7
[38] O que é um cache stampede e como evitá-lo?Uma chave quente expira e milhares de requisições falham juntas e atingem o banco. Correções: coalescência de requisições (single flight), lock curto por chave, renovação antecipada probabilística, TTLs com jitter, servir o valor antigo enquanto revalida. Aula 7
[39] LRU, LFU ou TTL?LRU expulsa o menos usado recentemente (bom padrão); LFU o menos usado em frequência (preserva os favoritos de longo prazo); TTL expira por idade, independentemente do uso. Caches modernos misturam (por exemplo, W-TinyLFU). Aula 7

Nas aulas: 7 · Cache · Catálogo: Cache

[40] Fila, pub/sub ou log de eventos?Fila: cada mensagem para um consumidor (distribuição de trabalho). Pub/sub: cada mensagem para todos os assinantes (fan-out). Log de eventos (Kafka): um log ordenado e retido que vários consumer groups leem cada um no seu offset, e podem reprocessar. Aula 8
[41] At-most-once, at-least-once, exactly-once?At-most-once pode perder mensagens; at-least-once pode duplicá-las (o padrão comum); "exactly-once", na prática, significa entrega at-least-once mais processamento idempotente ou transações. Aula 8
[42] Como o Kafka escala consumidores?Um tópico tem partições; dentro de um consumer group cada partição vai para um consumidor, então o paralelismo é no máximo o número de partições. A ordem só é garantida dentro da partição: use o id do pedido ou do assento como chave. Aula 8
[43] O que é o transactional outbox?Gravar a linha de negócio e o evento na mesma transação do banco (numa tabela outbox), e um relay publica os eventos. Evita o problema da escrita dupla, em que o banco confirma e a publicação falha. Aula 8
[44] Saga: coreografia ou orquestração?Uma saga divide uma transação distribuída em passos locais com compensações (liberar o assento se o pagamento falhar). Coreografia: os serviços reagem a eventos (solto, mais difícil de acompanhar). Orquestração: um coordenador conduz os passos (explícito, um componente a mais). Aula 8
[45] O que é backpressure, e uma DLQ?Backpressure: desacelerar os produtores ou recusar trabalho quando os consumidores não dão conta, em vez de deixar as filas crescerem para sempre. Uma dead-letter queue (DLQ) estaciona as mensagens que falham repetidamente para não travarem as demais. Aula 8

Nas aulas: 8 · Mensageria e arquitetura orientada a eventos · Catálogo: componentes de mensageria

[46] SLI, SLO, SLA e orçamento de erros?SLI: uma medida (fração de requisições abaixo de 300 ms). SLO: a meta (99,9% em 28 dias). SLA: um contrato com multas. Orçamento de erros: 100% − SLO, a falta de confiabilidade que você pode gastar com lançamentos e experimentos. Aula 9
[47] Timeout, retry, circuit breaker, bulkhead?O timeout limita a espera; o retry (com backoff e jitter) trata erros transitórios; o circuit breaker para de chamar uma dependência que continua falhando; o bulkhead isola recursos para que uma dependência lenta não consuma todos. Aula 10
[48] RPO vs RTO?RPO: quanto dado você pode perder (tempo desde a última cópia boa). RTO: quanto tempo até voltar. Backups dão horas; replicação dá segundos; multi-região ativo-ativo chega perto de zero, a um custo alto. Aula 10
[49] Por que engenharia do caos?Para achar fraquezas num experimento controlado, e não num incidente: declare uma hipótese sobre o estado estável, injete uma falha (latência, um crash, a queda de uma zona), observe, corrija. Comece pequeno, em homologação, com um botão de parada. Aula 10
[50] Métricas, logs e traces?Métricas: agregados baratos ao longo do tempo (algo está errado?). Logs: eventos detalhados (o que exatamente aconteceu?). Traces: uma requisição atravessando serviços (para onde vai o tempo?). O OpenTelemetry padroniza os três. Aula 9
[51] RED, USE e os sinais de ouro?RED para serviços: taxa, erros, duração. USE para recursos: utilização, saturação, erros. Os quatro sinais de ouro do Google: latência, tráfego, erros, saturação. Aula 9
[52] O que deve acordar alguém às 3 da manhã?Sintomas que os usuários sentem, não causas: um SLO consumindo rápido o orçamento de erros (alertas de burn rate em duas janelas). CPU alta, sozinha, não deve acordar ninguém. Aula 9

Nas aulas: 9 · Confiabilidade · 10 · Observabilidade · Catálogo: componentes de observabilidade

[53] Sub-redes públicas vs privadas, e um NAT gateway?Só o load balancer fica em sub-redes públicas; serviços e bancos ficam nas privadas, sem rota de entrada a partir da internet. Um NAT gateway permite que serviços privados chamem para fora (uma API de pagamento) sem ficarem acessíveis. Aula 12
[54] OAuth 2 / OIDC e JWT num fôlego só?O OIDC autentica o usuário e o servidor de autorização emite um token assinado (muitas vezes um JWT); os serviços verificam a assinatura e as claims localmente, sem chamar o servidor de autorização. Expiração curta mais refresh tokens; a revogação é a parte difícil. Aula 4
[55] O que um service mesh acrescenta?Uma camada de proxies (sidecar ou ambient) que dá a todo serviço mTLS, retries, timeouts, divisão de tráfego e telemetria sem mudar o código, ao custo de latência por salto e complexidade operacional. Aula 12
[56] Probes de liveness vs readiness?Liveness: o processo travou? (reinicie). Readiness: pode receber tráfego agora? (tire do load balancer). Verificar uma dependência na liveness causa tempestades de restarts. Aula 11
[57] Rolling, blue/green ou canary?Rolling troca os pods aos poucos; blue/green alterna todo o tráfego entre dois ambientes completos (rollback rápido, custo dobrado); canary envia uma pequena fração para a versão nova e observa as métricas antes de avançar. Aula 11
[58] Qual teste de carga responde a qual pergunta?Smoke: funciona? Load: cumpre o SLO no pico esperado? Stress: onde quebra? Spike: sobrevive às 10:00? Soak: degrada ao longo de horas? Breakpoint: qual é o máximo? Aula 15

Nas aulas: 11 · Rede e segurança · 12 · Cloud-native · 14 · Desempenho

[59] Por que colocar um LLM gateway na frente dos provedores de modelos?Um lugar único para rotear entre modelos, fazer fallback quando um provedor falha, aplicar cotas e orçamentos por time, cachear (exato e semântico) e medir tokens, custo e latência. Aula 13
[60] O que é RAG?Retrieval-augmented generation: dividir os documentos em trechos, gerar embeddings, guardar os vetores; na hora da pergunta, recuperar os trechos mais parecidos (vizinhos mais próximos aproximados, por exemplo HNSW), reordenar e colocá-los no prompt. Ancora a resposta nos seus dados. Aula 13
[61] O que é um loop de agente, e por que é lento?O modelo decide chamar uma ferramenta, o orquestrador a executa, o resultado volta ao modelo, e repete até terminar. Cada passo é uma chamada completa de LLM (muitas vezes 0,5–2 s), então latência e custo crescem com o número de passos; limite os passos. Aula 13
[62] O que é prompt injection e como se defender?Um texto não confiável (uma página web, um e-mail, uma avaliação) traz instruções que o modelo segue. Defesas: ferramentas com mínimo privilégio, confirmação para efeitos colaterais, separar instruções de dados, filtros de entrada e saída, nunca tratar a saída do modelo como autorização. Aula 13
[63] Como dimensionar um endpoint de LLM?Pense em tokens: requisições por segundo × tokens por requisição dá tokens por segundo; o tempo até o primeiro token (TTFT) e os tokens por segundo por fluxo definem a latência; custo ≈ tokens de entrada × preço + tokens de saída × preço. Aula 13

Nas aulas: 13 · Sistemas de IA e agentes · Catálogo: componentes de IA e agentes

Quiz

Vinte e quatro perguntas no estilo de entrevista, três por tema. Filtre por tema para revisar só o que precisa.

Plano de estudo

Como estudar, e um plano para as duas semanas antes de uma entrevista.

Em voz alta

Pratique em dupla

System design é uma prova oral. Ler soluções dá a sensação de aprender, e não é. Faça entrevistas simuladas com um colega, com cronômetro e a rubrica, e troquem de papel: ser o entrevistador ensina como soa uma boa resposta.

Com números

Saiba uma dúzia de cor

Segundos num dia, a escada de latências (memória, SSD, ida e volta no mesmo datacenter, entre continentes), o que um banco ou um Redis aguenta, os noves. A referência rápida e a página de números trazem todos.

Sob carga

Quebre no playground

Para cada design que praticar, monte-o no playground, rode um perfil de spike ou de stress e veja qual caixa fica vermelha primeiro. Depois corrija e rode de novo. Ver o joelho uma vez vale mais que ler sobre ele dez vezes.

Com honestidade

O checklist é o seu termômetro

Marque um item só quando conseguir explicá-lo a alguém sem anotações, com o trade-off. Espace as revisões: um dia, uma semana, um mês. O que você esquece entre as rodadas é o que precisa de atenção.

Dias	O que fazer
1–2	Fundamentos e estimativas: temas 1–2 acima e o quiz dos dois; estime cinco sistemas da lista de problemas em dez minutos cada
3	O framework: leia a página do framework; resolva o encurtador de URLs sozinho com 45 minutos no cronômetro e compare com o estudo de caso
4–5	Borda, computação e dados: CDN, load balancers, gateway, rate limiting; SQL vs NoSQL, índices, transações, replicação, sharding; o estudo de caso do rate limiter
6–7	Cache e mensageria: padrões, stampede, Kafka, outbox, sagas, idempotência; os estudos de caso de feed de notícias e de notificações
8	Confiabilidade e observabilidade: padrões de resiliência, SLOs, RED/USE; rode os cenários `cascading-failure` e `retry-storm` no playground
9	Dinheiro e disputa: os estudos de caso de ingressos e de pagamentos; explique três jeitos de evitar a venda dupla
10	Tempo real e IA: chat, transporte por aplicativo, assistente de IA
11–12	Duas entrevistas simuladas por dia em dupla, cronometradas, com a rubrica; o quiz completo, voltando só ao que errou
13	Comportamental: escreva três histórias do seu projeto (um trade-off, uma falha, uma medição)
14	Uma última passada pelo checklist, em voz alta; descanse

Para praticar no formato do curso: a apostila, com exercícios em três níveis e respostas comentadas. Para uma revisão rápida: a folha de consulta, o mapa de conceitos e os cartões de estudo.

Checklist

Os assuntos e hábitos de uma boa entrevista de system design. Seu progresso fica salvo neste navegador.

De volta às 10h

A resposta completa para "projete um site de ingressos para um show num estádio".

Fãs por assento

≈ 33

2 M de fãs para 60 mil assentos: a maioria não vai conseguir ingresso, então justiça e um "esgotado" claro importam tanto quanto a velocidade.

Pico às 10:00

~10⁵ req/s

Ilustrativo: 2 M de fãs atualizando a cada ~10–20 s nos primeiros minutos. Quase tudo leitura da mesma página de evento.

Escritas de assento

~10³/s

Ilustrativo: se os 60 mil assentos saírem no primeiro minuto, sem sala de espera. Pouco, mas tudo nas mesmas linhas: disputa, não volume. Uma sala de espera reduz isso ao ritmo que você escolher.

1

Esclareça"Funcionalidades centrais: ver o evento, escolher assentos ou recebê-los, segurá-los por alguns minutos, pagar, receber o ingresso por e-mail. Nunca vender um assento duas vezes; a página precisa ficar de pé às 10:00; justiça importa; bots são uma ameaça real. Fora do escopo: revenda, gestão do estádio." — tópicos [1], [9].

2

Estime"2 M de fãs, 60 mil assentos, cerca de 33 fãs por assento. As leituras no pico são da ordem de 10⁵ por segundo, quase todas da mesma página; as escritas de assento ficam em torno de mil por segundo, todas no mesmo evento. O problema de design é o pico e a disputa, não o armazenamento." — tópicos [3], [4].

3

Absorva o pico na borda"A página do evento e os assets vêm de uma CDN; a disponibilidade do mapa de assentos vem de um cache atualizado a cada segundo, o que é aceitável porque a verificação oficial acontece na hora da reserva. Um WAF e proteção contra bots, mais um rate limit por usuário no API gateway." — tópicos [15], [18], [19].

4

Transforme a multidão numa fila"Uma sala de espera virtual: às 10:00 os fãs recebem uma posição aleatória ou por ordem de chegada numa fila, e o gateway os admite no ritmo que o serviço de inventário aguenta, digamos 2.000 por minuto, com um token de admissão assinado. O pico vira um fluxo constante." — tópicos [24], [40], [45].

5

Faça do assento a fonte da verdade"Inventário no PostgreSQL, particionado por evento se necessário. Uma reserva é um único update condicional atômico (status = 'held', hold_until = now() + 10 min WHERE status = 'free'), então dois fãs nunca seguram o mesmo assento. Um job de expiração libera as reservas não pagas." — tópicos [30], [31].

6

Pague com segurança, confirme de forma assíncrona"O serviço de pedidos chama o provedor de pagamento com chave de idempotência, timeout e circuit breaker; o webhook do provedor confirma. O pedido é gravado junto com um evento OrderConfirmed num outbox; o Kafka o distribui para notificações, analytics e busca." — tópicos [13], [26], [43], [47].

7

Nomeie os trade-offs e como provaria"Consistência forte só para assentos e pedidos; todo o resto eventualmente consistente. A sala de espera troca um pouco da paciência do usuário por um sistema que não cai. Eu faria um teste de carga com perfil de spike e um game day em que o provedor de pagamento fica lento." — tópicos [8], [49], [58].

Sete passos, uma dúzia dos conceitos acima, e cada caixa justificada por um número ou um requisito. Era isso que a entrevistadora queria ver: não as caixas que você conhece, mas por que cada uma está ali. Experimente você mesmo no playground com o cenário flash-sale e compare com o estudo de caso de ingressos.

Referências

Para aprofundar, agrupadas por tipo.

A pergunta das 10h

Como é uma entrevista de system design

"Projete um encurtador de URLs"

"Torne este rate limiter distribuído"

"O p99 triplicou depois do deploy"

"Quantos servidores precisamos?"

O que o entrevistador avalia

Como responder

O framework, passo a passo

Diagnóstico rápido

"O p99 está em 4 s, a CPU em 15%"

O que usar quando

Os conceitos-chave

Quiz

Plano de estudo

Pratique em dupla

Saiba uma dúzia de cor

Quebre no playground

O checklist é o seu termômetro

Checklist

De volta às 10h

Referências

Preparação para entrevistas, neste curso

Material de apoio

Livros

Recursos gratuitos online