Como estruturar uma resposta de system design

O problema

A maioria das pessoas não trava em system design por falta de conhecimento técnico.

Trava por falta de ordem mental.

O entrevistador fala “desenhe um sistema para…” e a pessoa tenta pensar em:

• requisito
• banco
• cache
• fila
• API
• escala

Tudo ao mesmo tempo.

Esse caos costuma produzir dois tipos de resposta ruim:

• a resposta apressada, que pula direto para tecnologia
• a resposta vaga, que parece boa mas nunca fecha um desenho confiável

Modelo mental

Uma boa resposta de system design quase sempre cabe em cinco fases:

1. requisitos
2. estimativa de capacidade
3. API e dados
4. arquitetura de alto nível
5. deep dive no ponto crítico

Essa ordem importa.

Não porque exista ritual sagrado.

Mas porque cada etapa reduz ambiguidade para a próxima.

Se quiser resumir em uma frase:

Sua resposta não precisa provar que você conhece todo componente do mercado. Ela precisa provar que você sabe sair de um problema aberto e chegar a um desenho coerente.

Quebrando o problema

Fase 1: requisitos

Comece pelo que o sistema precisa fazer e pelo que mais importa para o negócio.

Aqui entram perguntas como:

• qual é o fluxo principal
• o que é obrigatório agora
• o que pode ficar de fora
• qual latência importa
• qual volume de uso estamos assumindo

Também vale separar requisito funcional de requisito de qualidade.

Exemplo:

• funcional: o usuário cria um link curto
• qualidade: o redirect precisa ser rápido mesmo com pico

Se o enunciado vier vago, não finja certeza. Faça uma suposição razoável.

Também não precisa transformar isso em interrogatório infinito.

Duas ou três perguntas que realmente mudam o desenho costumam valer mais do que uma lista longa de dúvidas para ganhar tempo.

Fase 2: estimativa de capacidade

Agora você coloca tamanho no problema.

Não para acertar número perfeito.

Nem para impressionar com conta complicada.

Para responder perguntas como:

• estou desenhando algo pequeno, médio ou muito grande?
• leitura domina escrita?
• esse volume cabe tranquilo ou já pede cuidado extra?

Sem essa etapa, fica fácil propor fila, particionamento ou cache sem saber se o problema realmente pede isso.

Em entrevista, uma boa estimativa não é a mais detalhada.

É a que já separa um sistema tranquilo de um sistema que vai sofrer na leitura, na escrita ou no armazenamento.

Fase 3: API e dados

Antes do diagrama geral, deixe o fluxo principal concreto.

Se for encurtador de URL, por exemplo:

• POST /urls
• GET /:shortId

Esse passo força respostas que o diagrama sozinho costuma esconder:

• qual é a chave principal
• o que precisa ser persistido
• o que é síncrono
• o que pode virar assíncrono

Fase 4: arquitetura de alto nível

Só agora faz sentido desenhar blocos principais.

Normalmente entram blocos como:

• cliente
• API
• banco
• cache
• fila
• workers
• storage

Mas a regra não é usar todos.

A regra é colocar só o que resolve um problema que já apareceu antes.

Fase 5: deep dive

Quase toda entrevista chega em um ponto mais sensível do sistema.

Pode ser:

• cache e invalidação
• geração de ID
• particionamento
• consistência
• reprocessamento

O deep dive é onde você mostra que entende consequência, não só blocos.

Exemplo simples

Imagine a pergunta:

Como você desenharia um encurtador de URL?

Uma resposta estruturada poderia seguir este ritmo:

1. “Vou confirmar o escopo: criar links curtos e redirecionar rápido. Analytics detalhado eu vou deixar como extra.”
2. “O fluxo principal é redirect, então leitura deve ser muito maior do que escrita.”
3. “Vou assumir 10 milhões de usuários ativos por dia e muitos redirects por link. Isso já me diz que o caminho de leitura merece atenção especial.”
4. “Minha API base seria POST /urls para criar e GET /:shortId para redirecionar.”
5. “Nos dados, preciso do mapeamento entre shortId e URL longa, talvez com expiração opcional.”
6. “No alto nível, eu teria API stateless, banco para persistência, cache para redirects quentes e pipeline assíncrono separado para analytics.”
7. “Se você quiser, eu aprofundo agora em geração de ID, colisão ou estratégia de cache.”

Perceba o que aconteceu:

• a resposta não correu
• a resposta não enrolou
• a resposta foi criando confiança em ordem

Erros comuns

• Começar listando tecnologia antes de explicar o fluxo.
• Pular requisito e estimativa porque “isso a gente vê depois”.
• Detalhar cedo demais e gastar tempo no que não é central.
• Escolher um deep dive aleatório em vez do ponto realmente sensível.
• Esperar um enunciado perfeito em vez de declarar suposições razoáveis.

Como um senior pensa

Quem já lidou com sistemas reais costuma ter uma calma diferente nesse tipo de pergunta.

Não porque sabe todas as respostas.

Mas porque sabe criar ordem no meio da ambiguidade.

O raciocínio costuma soar assim:

Primeiro eu enquadro o problema. Depois eu dimensiono. Depois eu escolho os blocos que resolvem o que apareceu. E só então aprofundo o ponto mais arriscado.

Essa postura evita desperdício e também soa confiável.

O entrevistador percebe que você não está reagindo ao acaso.

Você está conduzindo a conversa.

O que o entrevistador quer ver

Em system design, o entrevistador normalmente está avaliando se você:

• entende o problema antes de resolver
• consegue dimensionar sem fantasia
• conecta requisito a arquitetura
• sabe aprofundar trade-offs reais

O entrevistador não precisa que você desenhe o sistema perfeito.

Ele precisa acreditar que, diante de um problema aberto, você consegue organizar o pensamento e defender um caminho coerente.

Quando você escolhe uma ordem boa, até suas incertezas parecem mais maduras.

Elas deixam de soar como improviso e passam a soar como engenharia.

Em system design, estrutura da resposta conta quase tanto quanto o conteúdo.

Quando sua ordem mental aparece, seu julgamento técnico aparece junto.