Framework de system design interview
Ao terminar: Você estrutura qualquer entrevista de system design nos 5 passos do FRAME, sem travar no requisito não funcional.
O erro que elimina candidato nos 5 primeiros minutos
A entrevista de system design não é um teste de conhecimento — é um teste de como você lida com um problema mal definido. E o erro mais comum não é errar um número: é começar a desenhar antes de saber o que está sendo pedido. O candidato ouve "projete o Twitter", vai direto para caixas e setas, e quinze minutos depois descobre que o entrevistador queria discutir apenas o feed, para 10 mil usuários, sem multimídia.
O entrevistador enuncia o problema de forma vaga de propósito. A vagueza é o teste. Num trabalho real, ninguém entrega requisito pronto: alguém diz "precisamos de notificações" e cabe a você descobrir para quem, com que latência, e o que acontece quando falha.
O sintoma de que você caiu na armadilha
Se você desenhou um balanceador de carga antes de saber quantos usuários o sistema tem, você já está projetando para uma escala imaginária. Metade das decisões seguintes vai herdar essa suposição, e nenhuma delas terá justificativa quando o entrevistador perguntar "por quê?".
Os cinco passos, e quanto tempo cada um merece
Uma entrevista típica dura 45 a 60 minutos. A distribuição abaixo não é arbitrária: ela reflete onde a avaliação realmente acontece.
| Passo | Tempo | O que se avalia aqui |
|---|---|---|
| 1. Requisitos e escopo | 5–10 min | Se você pergunta antes de responder. Candidato que pula esta etapa é reprovado mesmo com o desenho certo |
| 2. Estimativa de escala | 5 min | Se os números guiam as decisões seguintes ou são decoração. Ordem de grandeza basta — precisão não é o ponto |
| 3. Desenho de alto nível | 10–15 min | Se o fluxo do dado é coerente de ponta a ponta. É a parte que o entrevistador consegue seguir |
| 4. Aprofundamento | 15–20 min | Onde a senioridade aparece. O entrevistador escolhe um componente e espera profundidade real |
| 5. Gargalos e trade-offs | 5 min | Se você conhece as fraquezas do que desenhou. Quem não aponta nenhuma não entendeu o próprio projeto |
A proporção diz o que importa
Trinta e cinco dos sessenta minutos são requisitos, escala e aprofundamento. O desenho bonito ocupa quinze. Candidato que gasta quarenta minutos desenhando caixas otimizou a parte menos avaliada.
Passo 1 — as perguntas que mudam o projeto
Nem toda pergunta vale o tempo. Estas cinco mudam a arquitetura de verdade; as outras podem ser assumidas em voz alta e seguir.
- Quantos usuários, e qual a razão entre leitura e escrita? Um sistema com cem leituras por escrita é resolvido com cache; um com escrita dominante não é.
- Qual latência é aceitável, e para qual operação? "Rápido" não é requisito. 200 ms na leitura e 2 s na escrita é requisito, e leva a decisões opostas.
- O dado pode ser eventualmente consistente? Esta é a pergunta que mais destrava projeto — se pode, cache, réplica e fila entram; se não pode, quase tudo fica mais caro.
- Qual o tamanho do objeto? Mensagem de texto e vídeo de 4K não compartilham nenhuma decisão de armazenamento.
- O que acontece se o sistema ficar fora do ar por cinco minutos? A resposta define quanto vale investir em disponibilidade — e ninguém pergunta isso.
Como declarar uma suposição sem parecer que está chutando
"Vou assumir 10 milhões de usuários ativos por dia e razão de 100 leituras por escrita — se isso mudar, a decisão de cache muda junto." Você amarrou a suposição a uma consequência. É exatamente o que se espera de quem vai tomar decisões sem supervisão.
Passo 2 — a estimativa que sustenta o resto
O objetivo não é acertar o número. É que as decisões seguintes tenham origem visível. Três contas bastam:
# 1. Requisições por segundo (a que dimensiona compute)
10M usuários/dia × 20 ações = 200M ações/dia
200M ÷ 86.400 s ≈ 2.300 req/s em média
Pico ≈ 2–3× a média → ~6.000 req/s
# 2. Armazenamento (a que decide o banco e o custo em 3 anos)
2M posts/dia × 1 KB = 2 GB/dia
× 365 × 3 anos ≈ 2,2 TB → cabe num nó; não precisa de shard AINDA
# 3. Banda (a que costuma ser esquecida, e é a que mais custa)
6.000 req/s × 10 KB de resposta = 60 MB/s de saída
Mídia muda tudo: 1 imagem de 500 KB por request → 3 GB/sO número que quase todo candidato esquece
Banda de saída é o item que mais aparece na fatura de infraestrutura real, e é o mais esquecido em entrevista. Ele é também o que justifica CDN — e "vou colocar um CDN" sem esse número é decoração, com ele é decisão.
Qual é o primeiro passo numa entrevista de projeto de sistema, e por que ele é pulado com frequência?
Passo 4 — onde a senioridade fica visível
O aprofundamento é a parte que separa níveis. O entrevistador aponta um componente e espera que você desça. A diferença entre júnior e sênior não é saber mais nomes — é saber o que quebra.
| Nível | Como responde a "como você escala o banco?" |
|---|---|
| Júnior | "Adiciono réplicas de leitura." Correto e incompleto: não diz o que acontece com a escrita, nem menciona o atraso de replicação |
| Pleno | "Réplicas de leitura para o tráfego de leitura, e particionamento quando a escrita saturar." Enxerga os dois eixos |
| Sênior | "Réplicas resolvem leitura, mas introduzem leitura desatualizada — preciso saber se a operação tolera. Particionamento resolve escrita, e custa junção entre partições e uma escolha de chave difícil de reverter. Antes dos dois, eu olharia o padrão de acesso: normalmente 80% do tráfego está em 20% dos dados, e cache resolve mais barato." |
O padrão da resposta sênior
Ela nomeia o custo de cada opção e propõe a mais barata primeiro. Não é conhecer mais tecnologia — é tratar cada escolha como troca, e não como receita.
Passo 5 — apontar as fraquezas do próprio desenho
Terminar dizendo "acho que está bom" é perder pontos de graça. O entrevistador já viu os problemas do seu desenho; a pergunta é se você também viu.
- Ponto único de falha: qual componente derruba o sistema inteiro se cair? Quase sempre existe um, e reconhecê-lo vale mais que fingir que não.
- Partição quente: qual chave concentra tráfego? Data, identificador sequencial e "usuário famoso" são os três suspeitos de sempre.
- O que acontece na falha parcial: se a fila está atrasada em dez minutos, o usuário vê erro, dado velho, ou nada? As três respostas são projetos diferentes.
- Custo: qual componente domina a conta, e o que você cortaria primeiro se o orçamento caísse pela metade?
A frase que fecha bem uma entrevista
"O maior risco deste desenho é a partição quente na chave de usuário: uma conta muito seguida concentra escrita. Eu trataria essas contas como caso especial, e mediria antes de otimizar." Você apontou o defeito, propôs solução e condicionou à medição — os três sinais que se procura.
Perguntas frequentes
❓ Como estruturar uma entrevista de system design?
❓ Quanto tempo gastar em cada etapa?
❓ O que o entrevistador realmente avalia?
Fixando
Por que a estimativa de escala precede as decisões de arquitetura?
O que costuma diferenciar uma resposta sênior de uma júnior nesse tipo de entrevista?
O que levar para a próxima entrevista
Pergunte antes de desenhar. Amarre cada suposição a uma consequência. Faça três contas e use os números para justificar decisões. Desça fundo em um componente. E termine apontando a fraqueza do que você mesmo projetou — é o que mais distingue quem já operou sistema em produção.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…