Entrevista de System Design: Como estruturar sua resposta

Intenção de busca: Engenheiros de nível intermediário a sênior que conhecem sistemas distribuídos mas travam quando precisam projetá-los ao vivo na frente de um entrevistador.

Por que bons engenheiros falham em entrevistas de system design

Você construiu sistemas distribuídos. Você depurou incidentes em produção. Você sabe o que é um CDN. E ainda assim, quando alguém diz "Projete o Twitter," sua mente fica em branco.

O problema não é conhecimento — é estrutura. Questões de system design são deliberadamente abertas. Sem um framework claro, você pula entre componentes, esquece de esclarecer requisitos e fica sem tempo antes de cobrir as partes importantes.

Os entrevistadores não estão avaliando seu diagrama final. Eles estão observando como você pensa: você coleta requisitos? Propõe um design? Identifica gargalos? Raciocina sobre trade-offs? Isso é o que a entrevista de system design realmente testa.

O Framework de 5 passos para qualquer entrevista de system design

Passo 1: Esclarecer requisitos (3–5 minutos)

Antes de desenhar qualquer coisa, faça perguntas. Isso não é uma tática para ganhar tempo — é a parte mais importante.

Requisitos funcionais — o que o sistema precisa fazer:

• Quais são as ações centrais do usuário? (postar, ler, buscar, seguir?)
• Quais casos de uso estão fora do escopo?

Requisitos não funcionais — como o sistema deve se comportar:

• Escala: quantos usuários ativos diários? Leitura ou escrita intensa?
• Metas de latência: o que é aceitável para a ação principal do usuário?
• Disponibilidade: qual é o SLA de uptime? Podemos tolerar breve indisponibilidade durante deployments?
• Consistência: é necessária consistência forte, ou eventual está bem?

Anote os números. "1M usuários ativos diários, proporção de leitura/escrita de 100:1, p99 < 200ms para leituras" — isso define cada decisão arquitetural que você tomará.

Não pule este passo mesmo que o enunciado pareça claro. Os entrevistadores deixam ambiguidade intencionalmente para ver se você vai perguntar.

Passo 2: Estimar escala (2–3 minutos)

Cálculos de ordem de grandeza fundamentam seu design. Para um sistema de leitura intensa com 10M DAU:

• Assuma 50 leituras/dia por usuário → 500M leituras/dia → ~6.000 leituras/segundo
• Armazenamento: se cada registro tem 1KB e você armazena 10M novos registros/dia → 10GB/dia → 3,6TB/ano

Esses números dizem se você precisa de um banco de dados único ou sharding, se um único nó de cache é suficiente e como deve ser sua estratégia de CDN.

Passo 3: Design de alto nível (10–12 minutos)

Agora desenhe. Comece com o design mais simples que satisfaz seus requisitos. Um bom design de alto nível para a maioria dos sistemas inclui:

• Cliente → API Gateway → Serviços de aplicação
• Bancos de dados — qual tipo e por quê (relacional, NoSQL, série temporal)?
• Cache — o que está sendo armazenado em cache e por quê?
• Processamento assíncrono — onde uma fila de mensagens se encaixa?
• CDN — para conteúdo estático ou leituras geograficamente distribuídas

Exemplo, um encurtador de URLs em escala:

1. Caminho de escrita: Cliente → API → Servidor de aplicação → BD (gravar mapeamento curto:longo) + Cache
2. Caminho de leitura: Cliente → CDN → Load balancer → App server → Cache (Redis) → BD em caso de cache miss
3. Geração de URL curta: Use ID baseado em contador com codificação base-62 ou gerador de ID distribuído (Snowflake)

Verbalize suas escolhas: "Estou usando PostgreSQL aqui porque os dados são relacionais e precisamos de consistência forte para escritas. Para leituras, vou colocar Redis na frente."

Passo 4: Aprofundamentos (10–15 minutos)

Após o alto nível, o entrevistador tipicamente vai guiá-lo às áreas que mais lhe importam. Tópicos comuns:

• Design de schema de banco de dados — quais são suas tabelas, índices, estratégia de sharding?
• Estratégia de cache — cache-aside vs. write-through? TTL? Invalidação de cache?
• Tratamento de hot spots — o que acontece quando os posts de um usuário famoso recebem 10M acessos?
• Consistência vs. disponibilidade — onde você está fazendo esse trade-off explicitamente?
• Data fan-out — para feeds sociais, como você propaga escritas para seguidores?

Aprofunde quando solicitado. O entrevistador quer ver você ir além de "coloque um cache na frente do banco de dados" para "aqui está a política de evicção, aqui está como lido com cache stampedes, aqui está o trade-off que estou fazendo."

Passo 5: Trade-offs e alternativas (5 minutos)

Encerre reconhecendo o que você deliberadamente deixou de fora ou simplificou. Isso é o que separa bons candidatos dos excelentes.

"Escolhi consistência eventual aqui para obter melhor throughput de escrita — mas se o negócio exigir que toda leitura reflita a última escrita, precisaria repensar isso com replicação síncrona, que adiciona latência."

Isso sinaliza maturidade de engenharia: você entende que toda decisão arquitetural é um trade-off, não uma resposta certa.

Perguntas comuns de entrevista de system design e o que realmente testam

Os maiores erros em entrevistas de system design

Ir direto para código ou diagramas. Comece com requisitos sempre, mesmo que o problema pareça óbvio.

Projetar o sistema perfeito. Não existe sistema perfeito. O entrevistador quer raciocínio sobre trade-offs, não um diagrama de livro didático.

Ficar em silêncio. Narre seu raciocínio em voz alta. Se você está considerando duas abordagens, diga isso. "Estou escolhendo entre X e Y — X nos dá melhor desempenho de escrita mas Y é mais fácil de escalar leituras. Dado nosso ratio de leitura de 100:1, vou com Y."

Ignorar escala. Cada decisão deve se conectar de volta aos seus números. "Isso funciona a 1K QPS, mas a 100K QPS precisaríamos de sharding — aqui está como eu abordaria isso."

Pratique agora

Conhecer o framework e aplicá-lo ao vivo sob pressão do entrevistador são duas coisas muito diferentes.

Experimente uma sessão gratuita no Interview Sparring →