System design: resposta confusa vs resposta forte

O problema

System design costuma dar a falsa impressão de que a melhor resposta é a mais sofisticada.

Não é.

O que derruba muita gente boa aqui é outra coisa:

• começa cedo demais em tecnologia
• tenta resolver tudo ao mesmo tempo
• fala de escala sem ter definido o fluxo principal
• joga componente no diagrama como se isso, por si só, provasse maturidade

Daí o entrevistador não escuta “essa pessoa sabe arquitetura”.

Escuta algo mais perto de:

• pensamento solto
• prioridade fraca
• repertório sem direção

Modelo mental

Pense assim:

em system design, resposta forte não é a mais cheia. É a mais organizada sob ambiguidade.

O entrevistador está tentando ver se você consegue sair de um problema aberto e construir, em voz alta, um desenho coerente.

Isso pede quatro coisas:

• enquadrar o problema
• reduzir ambiguidade
• tomar decisões legíveis
• aprofundar onde realmente dói

Sem isso, até resposta tecnicamente correta pode soar fraca.

Resposta confusa vs resposta média vs resposta forte

Resposta confusa

Pergunta:

Como você desenharia um sistema de notificações?

Resposta que soa confusa:

Eu teria um gateway principal, depois uma fila para desacoplar, um Redis para performance, talvez Kafka dependendo da escala, workers para processar, banco relacional para persistência, talvez NoSQL para histórico, e também pensaria em WebSocket para tempo real e fallback para push ou e-mail.

Por que ela sai fraca:

• começa por componente, não por problema
• mistura canal, persistência, escala e entrega sem ordem
• não deixa claro o fluxo principal
• parece mais lista de coisas conhecidas do que decisão

Não é que tudo ali esteja errado.

O problema é que a resposta ainda não construiu confiança.

Resposta média

Primeiro eu separaria os tipos de notificação e veria quais precisam ser em tempo real e quais podem ser assíncronas. Eu usaria uma API para receber eventos, colocaria em fila para processamento e teria workers por canal. Também persistiria o histórico e cuidaria de retry quando a entrega falhasse.

O que melhora:

• já existe alguma ordem
• já existe noção de fluxo
• já aparece preocupação com falha e retry

O que ainda falta:

• falta explicitar escopo e hipótese de volume
• falta justificar melhor as escolhas
• falta mostrar qual é o ponto mais sensível do sistema

Resposta forte

Eu começaria delimitando o escopo: estamos falando de um sistema que recebe eventos internos e dispara notificações por e-mail, push e in-app. O fluxo principal aqui não é só enviar; é garantir que cada canal tenha processamento confiável e observável. Antes de abrir o desenho, eu assumiria que o volume de escrita vem em bursts e que a entrega pode falhar de forma diferente por canal. Com isso, eu pensaria em uma API de ingestão simples, fila para desacoplar pico de entrada, workers separados por tipo de entrega e persistência suficiente para rastrear estado, retry e auditoria. Se você quiser, eu aprofundo agora no ponto crítico mais provável, que para mim é idempotência e política de retry sem duplicar envio.

Por que ela funciona melhor:

• começa pelo escopo
• define o que realmente importa no sistema
• transforma volume em direção, não em teatro de escala
• escolhe um ponto crítico plausível para aprofundar

O que muda na percepção

Quando a resposta vem confusa, a leitura costuma ser:

• “essa pessoa conhece peças, mas ainda não está dirigindo a conversa”
• “talvez saiba termos, mas não consigo confiar no critério”
• “vou precisar puxar estrutura dela”

Quando a resposta vem forte, a percepção muda para:

• “essa pessoa sabe reduzir ambiguidade”
• “consigo acompanhar o raciocínio”
• “parece alguém que consegue tomar decisão com contexto incompleto”

Essa diferença pesa mais do que o diagrama bonito.

O que uma resposta forte costuma fazer cedo

Uma resposta boa de system design normalmente faz algumas coisas logo no começo:

1. define o escopo
2. nomeia o fluxo principal
3. explicita hipótese de carga ou comportamento
4. transforma isso em escolhas arquiteturais legíveis
5. aponta o ponto crítico que merece deep dive

Isso não deixa a conversa rígida.

Deixa a conversa confiável.

Exemplo comparado

Pergunta:

Desenhe um encurtador de URL.

Resposta que sai solta:

Eu faria uma API, um banco, cache para os links, talvez CDN, talvez shard se a escala for muito alta, e depois teria analytics por fila.

Resposta que sai forte:

Vou assumir que o produto precisa criar links curtos e redirecionar rápido, e que analytics detalhado é secundário neste primeiro desenho. O fluxo dominante é leitura, então eu esperaria muito mais redirects do que criação de links. Com isso, minha API base seria simples, a persistência guardaria o mapeamento entre shortId e URL longa, e eu deixaria o caminho de redirect pronto para se beneficiar de cache nos links quentes. Se você quiser, eu aprofundo em geração de ID, colisão ou estratégia de invalidação.

Na segunda resposta, o entrevistador consegue ver:

• escopo
• prioridade
• justificativa
• direção de aprofundamento

Erros comuns

Tentar parecer completo demais

Resposta cheia demais costuma esconder o essencial.

Entrar em componente antes de fluxo

Banco, fila e cache só fazem sentido depois que o problema está minimamente no chão.

Falar de escala como performance

Escala sem hipótese de carga vira ornamentação.

Não escolher o que aprofundar

Quem não escolhe o ponto crítico transmite pouca leitura de risco.

Como um senior pensa

Quem responde melhor system design geralmente não está tentando provar que conhece o maior número de blocos.

Está tentando tornar claro:

• qual problema está resolvendo
• qual custo está aceitando
• onde o sistema tende a doer primeiro
• por que aquela arquitetura é suficiente para o cenário assumido

Isso soa mais senior do que qualquer lista de componentes.

Ângulo de entrevista

Essa pergunta aparece muito em loops de senior, full stack e backend.

E o padrão de erro se repete:

• o candidato sabe mais do que parece
• mas a resposta faz ele soar menos confiável do que realmente é

Por isso esse tipo de comparação vale tanto.

Ela mostra que, em system design, técnica importa.

Mas ordem mental e sinal percebido importam junto.