System design em entrevista júnior/pleno: o que cobram de verdade

A primeira etapa de system design da minha vida durou 45 minutos. Eu tinha passado a semana assistindo gente projetar o Twitter: sharding, fan-out, celebrity problem. O entrevistador pediu um encurtador de URL. No minuto três eu falei "sharding". Ele perguntou por quê. Eu não sabia. Naquela noite, anotei no caderno: pare de estudar pra vaga de staff sendo júnior.

Depois de 100+ entrevistas, o padrão ficou claro. De júnior e pleno, ninguém espera rede social global. Esperam que você monte um sistema pequeno e explique as suas escolhas. Só isso. E esse "só isso" reprova muita gente boa.

O que realmente cobram

Quatro peças. Quase toda pergunta de system design nesse nível cabe nelas:

• API. Endpoints, verbos, o que entra, o que sai. REST resolve. Se citar GraphQL, saiba defender o porquê.
• Banco. SQL ou NoSQL, com justificativa honesta. "Postgres, porque os dados são relacionais e eu conheço bem" já me passou de fase.
• Cache. Onde o Redis entra, o que você cacheia, o que acontece quando ele cai.
• Fila. O que é síncrono e o que não precisa ser. Mandar e-mail de confirmação não deveria segurar o request.

Os enunciados se repetem: encurtador de URL, sistema de notificações, rate limiter, um feed simples. Nenhum deles precisa de mais do que essas quatro caixas bem explicadas.

Tradeoff é a palavra da prova

O entrevistador não quer a arquitetura certa. Quer ver você trocar uma coisa por outra sabendo o que está trocando. Frases que me salvaram, em inglês mesmo:

• "I'd start with a single Postgres instance and add a read replica if reads become the bottleneck."
• "Caching makes this faster, but the data can get stale, so it depends on how fresh it needs to be."

Você não precisa dimensionar cluster. Precisa dizer que cache traz dado velho, que fila traz atraso, que replicar dado traz inconsistência. Uma frase por tradeoff. Eu decorei umas dez dessas e usei em quase toda entrevista dali em diante.

Falar em voz alta é metade da nota

Nas primeiras entrevistas eu desenhava em silêncio e apresentava o resultado no final. Errado. A avaliação é sobre o caminho, não sobre o desenho final. O mesmo princípio do live coding: silêncio não pontua.

Roteiro que passei a seguir, sempre narrando:

• Clarificar antes de desenhar. "How many users are we talking about? Is this read-heavy or write-heavy?"
• Montar o caso feliz de ponta a ponta: cliente, API, banco. Feio e funcionando.
• Só adicionar caixa nova (cache, fila, réplica) quando aparecer um motivo. E dizer o motivo em voz alta.

Quando o entrevistador pergunta "what if traffic grows 10x?", ele não está te derrubando. Está te entregando o roteiro. É o convite pra próxima caixa.

Como estudei sem me afogar

System design é um poço sem fundo. Eu me afoguei por umas três semanas em vídeo de arquitetura que eu nunca ia usar. O que funcionou foi encolher o escopo:

• Escolhi cinco problemas clássicos e repeti até explicar cada um em vinte minutos, sozinho, sem consultar nada.
• Aprendi dez conceitos de verdade (load balancer, cache, fila, index, réplica) em vez de cinquenta pela metade.
• Depois de cada entrevista, anotava o enunciado exato no caderno. Eles se repetem muito mais do que parece.
• Treinei explicando em inglês, falando com a parede. Metade das minhas travadas não era arquitetura, era vocabulário. Se esse é o seu caso, entrevista em inglês é um problema separado, e treinável em separado.

Essa etapa costuma aparecer depois do screening, antes ou depois do código ao vivo, dependendo da empresa. Vale conhecer as etapas do processo seletivo gringo pra não ser pego de surpresa como eu fui.

System design nesse nível é conversa técnica, não prova. Quem trata como conversa (pergunta, narra, justifica) passa na frente de quem decorou a arquitetura do Twitter. Levei uns quinze nãos pra entender. Está no caderno, na página em que escrevi "sharding" e, do lado, "nunca mais sem saber por quê".