O formato da entrevista de system design

Não existe gabarito

Todo outro round esconde uma resposta certa. O round de código tem uma suíte que passa. O de depuração tem um bug. Até o comportamental tem um formato de história que quem entrevista reconhece.

O round de design não tem nada disso. Duas pessoas fortes podem produzir arquiteturas completamente diferentes para o mesmo enunciado, e as duas serem contratadas. Alguém também pode produzir a arquitetura que quem entrevista usa no trabalho e mesmo assim ser reprovado.

O que se pontua não é o desenho em si. É se o seu raciocínio é legível, quantificado e honesto sobre os próprios custos.

O formato da hora

A maioria das sessões dura de 45 a 60 minutos. Este guia de ritmo aparece repetidamente, e vale guardá-lo na cabeça como orçamento, e não como lei:

As duas fases que as pessoas erram são a primeira e a última. Elas gastam um minuto em requisitos porque estão ansiosas para desenhar. Depois o relógio acaba antes da conversa de trade-offs, que é a parte de maior peso na pontuação.

Se você está 30 minutos dentro da sessão e ainda não disse um único número, está atrasado, por melhor que o diagrama pareça.

Quem entrevista é colaborador

Essa é a maior diferença de comportamento em relação ao round de código, e é a que derruba gente tecnicamente forte.

A pessoa não é uma examinadora esperando você terminar. Ela faz o papel de uma parte interessada que sabe a resposta que quer ver você descobrir, e vai guiar você se você deixar. Pergunte "isso precisa lidar com upload, ou é só texto?" e você recebe uma resposta real que evita cinco minutos projetando a coisa errada.

O silêncio é o principal modo de falha. Quem pensa por noventa segundos e depois apresenta uma ideia pronta não deu nada para pontuar, porque o que se pontua é o pensamento. Narre também os becos sem saída: "pensei em pôr isso no caminho da requisição, mas uma chamada externa de 300 ms ali estouraria a meta de latência, então vai para um job."

Quatro formas de perder esse round estando qualificado

A primeira é desenhar antes de delimitar. O enunciado é mal especificado de propósito. Desenhar primeiro significa projetar para um problema imaginado, e toda resposta posterior herda o erro.

A segunda é citar produtos em vez de componentes. "Eu usaria Kafka, Redis e Elasticsearch" é uma lista de compras. "Preciso de um log append-only com replay, então um log de mensagens durável, Kafka ou equivalente" é design. A segunda sobrevive ao "por que não só Postgres?", e a primeira não.

A terceira é aprofundar onde é confortável em vez de onde importa. Se a parte difícil do sistema é o fan-out e você gasta o mergulho no fluxo de login, mostrou que não sabe achar a parte difícil.

A quarta é nunca mencionar falha. Um design em que nada cai, nenhuma chamada de rede estoura o tempo e nenhuma fila acumula soa como um design que nunca foi operado. O que acontece quando o provedor terceiro fica seis horas fora é uma pergunta que você deveria levantar antes que a façam.

Ser uma pessoa Rails nessa sala

Dois modos de falha ficam de cada lado disso, e os dois são evitáveis.

O primeiro é esconder. Experiência com Rails é evidência de que você rodou um sistema real com um banco real sob carga real, e é essa experiência que o round testa. "Na prática, eu vi esse padrão aguentar até cerca de um milhão de linhas antes de o índice parar de caber na memória" vale mais que qualquer quantidade de vocabulário.

O segundo é responder a perguntas de arquitetura com recursos de framework. "Como você lidaria com um milhão de escritas por segundo?" não é uma pergunta sobre Active Record. Use o framework quando ele for a resposta. Por exemplo, quando o Solid Queue compartilha o seu banco primário, o estado do job fica na mesma transação do PostgreSQL que as suas linhas de negócio, e isso é um argumento de correção. Mas um round de design quer o mecanismo primeiro e a biblioteca depois.

A maioria de quem entrevista não liga se a sua resposta é implementável em Rails. Liga se você sabe o que está escolhendo.

O quadro geralmente não é um quadro

Quase todas essas sessões hoje são remotas, e isso muda a mecânica o bastante para valer um ensaio.

Você vai receber uma ferramenta de desenho compartilhada, um documento compartilhado ou uma tela em branco com a instrução de compartilhar a sua. As três recompensam a mesma preparação: decida antes como são as suas caixas, e pare de decidir isso durante o round. Use um retângulo para serviço, um cilindro para armazenamento e uma seta rotulada para a direção em que o dado anda, e nada além disso. As pessoas perdem minutos escolhendo formas.

Dois hábitos práticos valem mais que habilidade de desenho. Primeiro, escreva os requisitos num canto e deixe-os visíveis. No minuto trinta, você pode apontar para a restrição que está atendendo em vez de tentar lembrar dela. Segundo, rotule cada seta com o que corre por ela, como "id da fatura" em vez de um traço sem rótulo. Uma seta sem rótulo esconde o acoplamento sobre o qual vão querer perguntar.

Se a ferramenta brigar com você, diga isso e continue falando. Ninguém nunca reprovou nesse round por um diagrama feio, e muita gente reprovou por ficar em silêncio consertando um.

O que você vai projetar aqui

As lições 2 a 4 constroem um enunciado de ponta a ponta: a entrega de faturas do Meridian, o sistema de faturamento em Rails 8 do curso anterior. Ele tem quatro mil contas e faturas geradas toda noite. Cada fatura precisa chegar ao cliente por e-mail, por webhook e pela API, de forma confiável, sem duplicatas e sem o fechamento mensal derrubar tudo.

Esse enunciado foi escolhido porque contém todas as primitivas que o round testa: um fan-out, uma dependência externa que falha, uma história de retry, um pico e um requisito de correção que não dá para enrolar.

O que este curso cobre

1. O formato da entrevista de system design: esta lição
2. Requisitos e estimativa de capacidade: transformar um enunciado vago em números
3. Modelagem de dados em escala: chaves, índices, particionamento e a restrição que surpreende
4. Cache, filas e réplicas de leitura: as três primitivas, e quando cada uma é a errada
5. Rate limiters e caches LRU em Ruby: com um desafio em que você constrói um
6. Enunciados clássicos, encurtador, feed e notificações: os três que vão pedir de verdade
7. Sessão de quadro, juntando tudo: uma rodada completa com pontuação

Comece onde o round começa, e onde boa parte dele é ganha: recuse-se a desenhar qualquer coisa antes de saber o que está construindo.