Mock system design round: simulação com avaliação e resposta melhorada

O problema

System design vira caos quando a pessoa tenta provar repertório cedo demais.

Ela ouve um enunciado aberto e começa a despejar:

• fila
• cache
• Kafka
• Redis
• particionamento
• microsserviço

Tudo isso pode até aparecer depois.

Mas, se entrar cedo demais, a resposta perde forma.

Mock de system design serve para treinar justamente isso:

• ordem
• recorte
• justificativa
• ajuste sob follow-up

Como usar este mock

O melhor uso é este:

1. leia só o prompt
2. responda em voz alta por 12 a 15 minutos
3. pare antes da avaliação
4. compare sua resposta com a leitura crítica
5. regrave uma versão mais limpa

O objetivo não é decorar um desenho.

É treinar um jeito confiável de conduzir a conversa.

Prompt

Você precisa desenhar um sistema de notificações para um produto SaaS. O sistema deve enviar e-mail, push e notificação in-app para eventos como alerta de segurança, mudança de status de pedido e campanhas não críticas. Como você começaria a pensar a solução?

Resposta inicial do candidato

Eu faria um serviço de notificações que recebe eventos, coloca em uma fila e workers enviam para cada canal. Guardaria as notificações em banco e colocaria retry se o provider falhar. Dependendo da escala, também pensaria em Kafka ou Redis.

O que essa resposta tem de bom

• percebeu cedo que entrega deve ser assíncrona
• separou geração de evento de envio
• já notou que provider pode falhar

Onde ela ainda perde força

• não delimitou requisito nem prioridade
• tratou todos os tipos de notificação como se fossem iguais
• citou componentes cedo demais
• não mostrou critério de roteamento, preferência nem deduplicação

Até aqui, a resposta parece correta.

Mas ainda parece genérica.

Follow-up 1

Pergunta do entrevistador:

Nem toda mensagem tem a mesma urgência. O que isso muda no seu desenho?

Resposta fraca:

Eu criaria uma fila para notificações urgentes e outra para o resto.

Resposta melhor:

Isso muda bastante porque deixa claro que eu não posso tratar alerta de segurança, atualização operacional e campanha no mesmo fluxo. Eu separaria pelo menos categoria e prioridade cedo no pipeline, porque isso afeta SLA, canal preferido e política de retry. Alerta crítico talvez aceite múltiplos canais e menos atraso. Campanha não crítica pode tolerar batching, atraso e até cancelamento se o usuário já interagiu por outro caminho.

Aqui a resposta melhora porque:

• transformou requisito em decisão de arquitetura
• mostrou que prioridade não é só detalhe de fila
• conectou negócio, canal e entrega

Follow-up 2

Pergunta do entrevistador:

Como você evitaria duplicação quando o provider fica instável e retries começam a disparar?

Resposta apressada:

Eu limitaria retry.

Resposta melhor:

Retry sozinho não resolve porque o problema pode ser justamente incerteza de entrega. Eu tentaria modelar a entrega com idempotência e estado explícito de tentativa. Cada notificação precisa de um identificador estável por destinatário, evento e canal, e eu registraria tentativas com status para não reenviar no escuro. Se o provider devolver identificador próprio, eu também guardaria isso. A ideia é não tratar falha de rede como prova de não entrega.

Aqui aparecem:

• noção de deduplicação real
• diferença entre falha de transporte e falha de negócio
• preocupação com rastreabilidade

Follow-up 3

Pergunta do entrevistador:

O usuário pode escolher canal preferido e horário silencioso. Onde isso entra?

Resposta rasa:

Eu salvaria preferência do usuário no banco.

Resposta melhor:

Preferência não é só dado de perfil; ela participa do roteamento. Então eu colocaria essa decisão entre trigger e entrega. O evento entra, o sistema avalia categoria da mensagem, preferência do usuário, quiet hours e regras de fallback. Isso evita empurrar decisão de canal para o worker de entrega sem contexto suficiente. Também ajuda a explicar por que nem toda notificação vira tentativa em todos os canais.

Avaliação do entrevistador

Se o candidato parasse na resposta inicial, a leitura provável seria:

• conhece padrão básico
• ainda sem muito critério
• parece repetir desenho conhecido

Quando ele melhora nos follow-ups, o sinal sobe porque começam a aparecer:

• requisito que realmente muda o desenho
• separação entre trigger, roteamento e entrega
• raciocínio de idempotência e confiabilidade
• justificativa mais limpa para escolha de componentes

Em system design, esse salto costuma valer mais do que citar tecnologia “mais parruda”.

Resposta melhorada

Se eu condensasse uma resposta mais forte desde o começo, ela soaria perto disto:

Eu começaria delimitando quais categorias de notificação estamos tentando suportar no primeiro corte, porque alerta crítico, atualização operacional e campanha não merecem o mesmo fluxo. Com esse recorte, eu separaria o sistema em três partes: trigger, roteamento e entrega. O trigger nasce de eventos do produto. O roteamento decide se aquela mensagem deve sair, com qual prioridade, em qual canal e respeitando preferência do usuário e horário silencioso. A entrega conversa com providers de e-mail, push e com o canal in-app. Eu manteria a entrega fora do fluxo principal e trataria cada envio com identificador estável e estado de tentativa para suportar retry sem duplicação cega. Se você quiser, eu posso aprofundar agora em deduplicação, preferência do usuário ou capacidade e gargalo do pipeline.

Por que essa versão sobe o nível

• começa por requisito e categoria, não por componente
• organiza o sistema em partes legíveis
• deixa claro onde entra preferência e prioridade
• trata confiabilidade como parte do desenho
• oferece um deep dive plausível

Ela não tenta parecer perfeita.

Ela tenta parecer orientada.

E isso costuma ser o sinal certo.

O que poderia melhorar ainda mais

Se o entrevistador apertar mais, ainda daria para aprofundar:

• estratégia de outbox e publicação de eventos
• modelagem de auditoria e histórico
• throughput por categoria
• fallback de canal
• observabilidade do pipeline

Mas tudo isso entra melhor depois que o esqueleto do desenho já ficou claro.

Erros comuns nesse formato

• tratar mensagem crítica e marketing como o mesmo problema
• citar fila, cache e streaming antes de enquadrar o fluxo
• responder preferência do usuário como detalhe de banco
• esquecer deduplicação quando fala de retry
• usar follow-up só para anexar tecnologia nova

Ângulo de entrevista

Esse mock é útil porque simula um padrão muito comum:

• sistema aberto
• requisito que parece simples no começo
• follow-up que revela nuance real
• pressão para justificar por que o desenho faz sentido

Se você treina bem esse formato, melhora não só system design.

Melhora a forma como pensa arquitetura em voz alta.