Entrevista técnica B2: system design

Nível: B2

Objetivo

Conduzir (ou participar) uma entrevista de system design em inglês com estrutura visível: clarifying questions, requirements, constraints, high-level design, bottlenecks, trade-offs, e fechamento com o que o candidato faria diferente em produção.

Explicação

System design B2 não é sobre 'saber a resposta certa', é sobre mostrar como você pensa sob incerteza. A estrutura canônica é: clarifying questions (5–10 minutos, vague → concreto), requirements (functional e non-functional, com números), constraints (throughput, latency, durability, consistency), high-level design (caixas e setas, sem implementação), deep dives nos componentes críticos, bottlenecks and trade-offs, e closing com 'o que você faria diferente em produção?'.

Marcadores verbais B2 importantes: 'let me make sure I understand the requirements before I propose anything', 'the main constraint here is X', 'here is the high-level design', 'the trade-off is Y vs Z', 'the bottleneck is X, and the mitigation is Y', 'in production I would add W'. Eles mostram processo, não apenas resposta. O oposto é pular direto para o design, defender a primeira ideia, e fechar sem reconhecer trade-offs.

O entrevistador bom B2 também faz o oposto: ouve o candidato, anota o que foi coberto, e segue a estrutura em vez de caçar a 'resposta certa'. O candidato bom B2 faz perguntas antes de desenhar, fala enquanto desenha (think aloud), e sempre volta aos requirements: 'this is consistent with the latency requirement of 100ms p95'. Sem requirements explícitos, qualquer design vira 'achismo'.

Erros comuns: ir direto para o design sem clarifying, defender a primeira ideia sem trade-offs, falar de implementação antes do high-level, esquecer de non-functional requirements, e fechar sem 'o que você faria diferente em produção'. O bom system design B2 termina com autoavaliação: 'here is what I would change in production after this interview'.

Exemplos

Erros comuns

• Pular direto para o design sem clarifying: o candidato erra o problema antes de começar.
• Defender a primeira ideia sem trade-offs: mostra falta de processo, não de conhecimento.
• Falar de implementação antes do high-level: perde a visão de sistema.
• Esquecer non-functional requirements: latência, throughput, durabilidade, consistência definem o design.
• Fechar sem 'o que faria diferente em produção': perde a chance de autoavaliação honesta.
• Não falar enquanto desenha: o entrevistador não sabe o que você está pensando; think aloud é o processo.
• Não voltar aos requirements: 'isso é consistente com X' ancora a conversa e mostra processo.
• Fingir que sabe uma tecnologia que não domina: B2 prefere honestidade ('I would not pick this in production because I don't have enough experience with it; here is how I would validate').

Prática guiada

Reescreva cada momento abaixo no padrão B2 de system design. O objetivo é clarifying, requirements, trade-offs, e fechamento com autoavaliação.

• Pular para o design: 'Vou usar Kafka.'

→ Versão B2: *Let me make sure I understand the requirements before I propose anything. What is the expected throughput? What is the consistency model? The main constraint is 100ms p95 latency, so the trade-off here is consistency versus availability; we are choosing availability for this product.* Explicação: clarifying + requirements + trade-off explícito.

• Defender primeira ideia: 'Esse design é o melhor.'

→ Versão B2: *Here is the high-level design. The trade-off is consistency versus availability; we are choosing availability. The bottleneck is the read path, and the mitigation is a read-through cache with a five-minute TTL. In production I would add a circuit breaker and a feature flag for the cache.* Explicação: design + trade-off + bottleneck + mitigação + fechamento com autoavaliação.

Resumo

System design B2 é processo sob incerteza: clarifying questions → requirements → constraints → high-level design → bottlenecks and trade-offs → closing with production reality check. Marcadores: *let me make sure I understand the requirements*, *the main constraint is X*, *the trade-off is Y vs Z*, *in production I would add W*. Não há 'resposta certa' — o que importa é o processo.

História: Entrevista técnica B2: system design

Nível: B2

História em inglês

Clarifying questions

The interviewer asked Priya to design a search system. Priya opened with clarifying questions instead of jumping to a design. She asked, what is the expected throughput? Ten thousand QPS, the interviewer said. She asked, what is the consistency model? Eventually consistent is fine for this product, he said. She asked, what are the non-functional requirements? One hundred milliseconds p95 latency and 99.9% availability, he answered. She said, let me make sure I understand the requirements before I propose anything.

High-level design and trade-offs

Then Priya moved to the high-level design. She said, here is the high-level design: clients hit the API gateway, which fans out to the search and ranking services. The interviewer asked, where is the cache? Priya answered, in front of the search service, with a read-through cache and a five-minute TTL. The interviewer asked, what is the trade-off? Priya answered, the trade-off here is consistency versus availability; we are choosing availability for this product, with a five-minute TTL on the cache. She added, the bottleneck is the read path under batch load, and the mitigation is the read-through cache.

Closing with production reality check

The interviewer asked, what would you do differently in production? Priya answered, in production I would add a circuit breaker around the ranking service and a feature flag for the cache. The interviewer asked, how would you validate the cache hit ratio? Priya said, a back-of-the-envelope: at 10k QPS with 60% hit ratio, the cache handles 6k QPS, the origin handles 4k; both need to stay under the p95 budget. The interviewer asked, what about consistency? Priya said, this is consistent with the latency requirement of 100ms p95; if the product later needs stronger consistency, we would add a write-through layer behind the cache. She ended with one honest caveat. I would not pick Kafka in production for the indexing pipeline without a small prototype with a synthetic load, she said. The interviewer nodded; Priya had shown process, trade-offs, and self-awareness under uncertainty.

Tradução linha por linha

Notas de vocabulário

• let me make sure I understand the requirements before I propose anything = abertura B2: clarifying antes do design; processo, não resposta.
• what are the non-functional requirements? = non-functional define o design; latência, throughput, disponibilidade, consistência.
• here is the high-level design: clients hit the API gateway, which fans out = high-level em uma frase; caixas + setas, sem implementação.
• the trade-off here is consistency versus availability; we are choosing availability for this product = trade-off explícito + escolha com razão, não a 'resposta certa'.
• the bottleneck is the read path under batch load, and the mitigation is the read-through cache = bottleneck + mitigação ancorados no design.
• in production I would add a circuit breaker and a feature flag for the cache = fechamento com o que faria diferente em produção; autoavaliação honesta.
• a back-of-the-envelope: at 10k QPS with 60% hit ratio, the cache handles 6k QPS = cálculo de ordem de grandeza ancora números sem calculadora.
• this is consistent with the latency requirement of 100ms p95 = volta aos requirements; ancora a conversa em critérios, não em opinião.
• I would not pick Kafka in production for the indexing pipeline without a small prototype = honestidade B2: não sei, mas sei como validar.

Perguntas de compreensão

1. Why did Priya open with clarifying questions instead of jumping to a design?
2. What requirements did Priya extract from the interviewer?
3. How did Priya present the high-level design?
4. What was the trade-off, and what did Priya choose?
5. How did Priya identify the bottleneck and the mitigation?
6. How did Priya answer the closing question about what she would do differently in production?
7. Why did Priya use a back-of-the-envelope for the cache hit ratio?
8. Why did Priya acknowledge the consistency caveat and the Kafka prototype risk?
9. What was the strongest B2 signal in Priya's interview?

Prática com a história

1. Reescreva: 'Vou usar Kafka.' (system design B2)
2. Reescreva: 'Esse design é o melhor.' (system design B2)
3. Reescreva: 'Vou implementar com Docker, Kubernetes e Postgres.' (high-level B2)
4. Reescreva: 'Acho que está bom, vamos fechar.' (fechamento B2)
5. Traduza: 'Aqui está o design de alto nível: clientes batem no API gateway, que distribui para os serviços de busca e ranking.'
6. Traduza: 'Quais são os requisitos não-funcionais para os quais devo projetar?'