O framework de cinco fases (ritmo para 45 minutos)
- Requisitos: 5 minutos. Separe os funcionais (“encurtar uma URL, redirecionar, aliases personalizados?”) dos não funcionais (escala, metas de latência, disponibilidade vs. consistência, durabilidade). Peça números: usuários, leituras vs. escritas, volume de dados. Depois, diga o seu escopo em voz alta: “Vou projetar para 100 milhões de DAU, com predominância de leitura de 100:1 e redirecionamentos abaixo de 100 ms, e deixar analytics de fora, a menos que sobre tempo.” Delimitar o escopo em voz alta é o movimento que mais conta pontos em toda a etapa.
- Estimativa: 5 minutos. Cálculos aproximados de QPS, armazenamento e largura de banda. Arredonde para potências de dez, declare as premissas e confira se o resultado faz sentido (“500 milhões de URLs novas por mês ≈ 200 escritas/s, algo modesto; leituras a 100:1 ≈ 20 mil/s, e é isso que direciona o design”). O objetivo não é a precisão; é mostrar que os números guiam as suas escolhas de arquitetura.
- Design de alto nível: 10 minutos. Caixas e setas para o caminho feliz: clientes, balanceador de carga, camada de aplicação stateless, bancos de dados, cache, fila. Percorra uma requisição de ponta a ponta em voz alta. Prefira o convencional: novidade aqui é risco sem recompensa.
- Aprofundamentos: 20 minutos. O entrevistador escolhe um componente (“como exatamente a geração de IDs evita colisões?”, “o que acontece quando um nó de cache cai?”). É aqui que os níveis se separam. Seja concreto: modelo de dados, escolha da chave de partição, modos de falha, o que acorda o plantão às 3 da manhã.
- Fechamento: 5 minutos. Os gargalos que você atacaria em seguida, o que monitoraria, o que deixou de fora de propósito. Terminar com as limitações conhecidas passa senioridade, não fraqueza.
O vocabulário de trade-offs que sinaliza senioridade
Os entrevistadores observam se você recorre a estes eixos por conta própria:
| Eixo | A frase que conta pontos |
|---|---|
| Consistência vs. disponibilidade | “Para a contagem de seguidores, eu aceitaria dados desatualizados; para o registro de pagamentos, não. Bancos diferentes para garantias diferentes.” |
| Latência vs. custo | “Colocar em cache o 1% de chaves mais acessadas atende ~90% das leituras; colocar tudo em cache triplica a memória para um ganho marginal na taxa de acerto.” |
| Push vs. pull | “Fan-out na escrita para usuários comuns, fan-out na leitura para contas de celebridades: um modelo híbrido, definido pelo número de seguidores.” |
| SQL vs. NoSQL | “O padrão de acesso é chave-valor pelo código curto, sem joins. É isso que justifica um banco wide-column aqui, não a moda.” |
| Síncrono vs. assíncrono | “O usuário precisa da confirmação da escrita; o fan-out das notificações pode ir por uma fila e ser entregue depois, de forma eventual.” |
A metarregra: nunca cite uma tecnologia sem citar a propriedade que justifica o lugar dela. “Kafka” é uma palavra; “um log particionado, para que os consumidores possam reprocessar as mensagens depois de uma falha” é um motivo.
As dez questões de system design mais comuns, com o ponto central de cada uma
- Encurtador de URL. Ponto central: geração de IDs (contador + base62 vs. hash + tratamento de colisões) e cache no caminho de leitura. Aquecimento clássico: espere perguntas adicionais sobre analytics e expiração.
- Sistema de chat (WhatsApp/Slack). Ponto central: gerenciamento de conexões (WebSockets, presença), ordenação das mensagens por conversa, garantias e confirmações de entrega, sincronização offline.
- Feed de notícias (Twitter/Instagram). Ponto central: estratégia de fan-out e o problema das celebridades; ranqueamento como serviço separado; paginação por cursores, não por offsets.
- Rate limiter. Ponto central: escolha do algoritmo (token bucket vs. janela deslizante), contagem distribuída (Redis + Lua), fail-open vs. fail-closed e onde ele fica (no gateway vs. em cada serviço).
- Armazenamento de arquivos (Dropbox/Drive). Ponto central: divisão em blocos (chunking) e deduplicação, protocolo de sincronização e resolução de conflitos, separação entre metadados e blobs.
- Plataforma de vídeo (YouTube). Ponto central: pipeline de upload (transcodificação como jobs assíncronos), estratégia de CDN, bitrate adaptativo; economia do armazenamento.
- Pareamento de corridas (Uber). Ponto central: indexação geoespacial (geohash/quadtree), volume de escrita das atualizações de localização, pareamento como serviço stateful, preço dinâmico como um feed de preços.
- Sistema de notificações. Ponto central: abstração multicanal (push/e-mail/SMS), preferências e limites de frequência por usuário, idempotência e novas tentativas com deduplicação, filas de prioridade.
- Cache distribuído. Ponto central: consistent hashing, política de remoção (eviction), cache-aside vs. write-through, proteção contra o efeito manada, o thundering herd (agrupamento de requisições, TTLs com jitter).
- Sistema de métricas e monitoramento. Ponto central: volume de escrita de séries temporais, downsampling e camadas de retenção, explosão de cardinalidade de tags, avaliação de alertas como processamento em streaming.
Pratique pelo menos três de ponta a ponta, em voz alta, em um quadro branco ou em um documento, no ritmo de 45 minutos. Narrar um design e escrevê-lo são habilidades diferentes, e a entrevista avalia a narração. Uma simulação com um assistente de entrevista com IA dá a você um feedback no nível da transcrição, mostrando exatamente onde a sua explicação perdeu o fio; o ChadFlow também pode acompanhar a janela do seu diagrama durante uma etapa ao vivo e ajudar quando chega uma pergunta adicional.
As cinco formas como os candidatos são reprovados nesta etapa
- Pular os requisitos. Projetar lindamente o sistema errado é a falha mais comum. Trinta segundos delimitando o escopo evitam isso.
- Teatro de estimativa. Fazer contas e depois nunca usar os números. Se a sua estimativa de QPS não muda o seu design, foi só encenação.
- Arquitetura de buzzwords. Soltar Kafka/Cassandra/Kubernetes sem a justificativa baseada em propriedades descrita acima.
- Fazer monólogo. A etapa é um teste de colaboração. Consulte o entrevistador: “quer que eu me aprofunde na camada de armazenamento ou passe para a API?”
- Não prever falhas. Todo componente que você desenha deve ter uma resposta para “o que acontece quando isto cai?”. Prepare a resposta antes de desenhar a caixa.
Narre designs como quem já fez isso antes.
O ChadFlow transcreve as suas simulações de etapas de design, orienta as suas explicações entre uma sessão e outra e ajuda ao vivo vendo apenas a janela do seu diagrama, invisível no compartilhamento de tela.
Baixar o ChadFlow