Plano
É muito importante ter. Mesmo que você cometa um erro em algum lugar e siga o caminho errado em seu raciocínio, a abordagem estruturada geral fará o seu melhor. No início, você pode moderadamente embotar e perguntar ao entrevistado sobre os detalhes, mas a partir de um certo ponto (que no meu plano abaixo corresponde ao ponto 3) você deve ter a iniciativa por completo e é melhor não desistir até o final. Meu plano era mais ou menos assim:
- Reúna uma lista dos principais recursos e escreva-os no canto do quadro. Este truque simples o ajudará a lembrar uma restrição ou suposição importante.
- Entenda quais características técnicas o sistema deve ter: RPS esperado, faixa de tempos de resposta aceitáveis, expectativas em termos de consistência e confiabilidade.
- Construa a solução mais simples de uma máquina que funcione de alguma forma. Não há necessidade de começar com 20 datacenters em todo o mundo, é muito melhor chegar a isso gradualmente.
- Encontre um único ponto de falha ou gargalo de desempenho.
- Ofereça uma ou mais opções para resolver o problema, explique claramente os prós e os contras de cada uma delas
- Escolha uma das opções e vá para o passo 4, se ainda houver tempo, e se terminar, vá para o próximo item
- Estime o tamanho do armazenamento, o número de servidores, a largura de banda da rede e anote tudo com cuidado
- Bônus: fale sobre recursos adicionais, implementação de ML, métricas de produto, experimentos
O controle do tempo é muito importante. Tentei gastar 5 a 10 minutos nos dois primeiros pontos e 5 minutos nos dois últimos.
Tradeoffs
Eles precisam ser falados, mesmo que pareçam óbvios. Depois de introduzir qualquer peça nova, é importante dizer algo como "adicionamos um novo elemento, isso vai resolver tal e tal problema, mas vamos pagar por isso." As compensações podem ser mais ou menos assim:
- Quaisquer novos componentes do sistema ou um aumento no número de peças sobressalentes existentes resolvem o problema de velocidade de carga / resposta, mas adicionam dores de cabeça com suporte e implantação.
- A fragmentação resolve as restrições de carga e espaço, mas adiciona problemas de fragmentação no futuro.
- O armazenamento replicado resolve o problema de carga e confiabilidade, mas no caso de réplicas de leitura e gravação, faz você pensar sobre valores podres e a oposição de disponibilidade e consistência
- O cache resolve o problema de carregamento, mas faz você pensar sobre valores rançosos e coerência do cache.
- Sua própria solução pode ser facilmente modificada e otimizada para suas necessidades, mas você precisa escrevê-la primeiro.
- O bom da solução existente é que ela já existe, mas você precisa descobrir.
Números
Todo mundo sabe sobre os números de latência que todo programador deve saber , mas os números no link, em minha opinião, não são estruturados da maneira mais conveniente e reformatei-os durante a preparação para facilitar a memorização.
Em última análise, o seguinte é importante:
- Saiba o tempo gasto lendo dados de diferentes níveis de caches de processador, memória, SSD, HDD e rede.
- Lembre-se do tempo de viagens de ida e volta dentro do data center e ao redor do mundo, bem como a latência mínima que uma pessoa percebe como lag (~ 100ms).
- Para ser capaz de converter bytes em gigabytes, nanossegundos em segundos, etc., desenvolvi essa habilidade por conta própria no processo de prática.
Prática
Comprei um quadro branco, peguei os serviços existentes e tentei descobrir como faria do zero. Desenhei diagramas no quadro, descobri a carga e os recursos necessários, procurei pontos fracos no meu design. Também tenho grandes amigos com quem organizamos pseudo-seções e treinamos uns nos outros - foi uma experiência super gratificante. Após a prática, você pode ficar online e verificar como isso é feito de fato, e então tentar novamente. Depois de 10-20 rodadas com serviços diferentes, a iluminação se instala e as partes recorrentes individuais nos sistemas existentes começam a ser claramente visíveis. As peças sobressalentes podem ser, por exemplo:
- Pesquisa (de preferência com a capacidade de atualizar o índice em tempo real)
- (gfs, haystack)
- kv- (cassandra, dynamo)
- Message queue pub-sub (kafka)
- (twitter, instagram, facebook)
- , , - (whatsapp, telegram, battle.net)
- , - (skype, twitch, youtube)
- Grokking the system design interview. , , .
- System design primer. , .
- ( ). . , , .
- Uma grande seleção de alta escalabilidade
- Bem, o recurso mais importante são seus amigos e conhecidos que sabem como seus sistemas funcionam e podem falar sobre eles.
Vários bons vídeos e canais
1. Escalabilidade
2. Entrevistas de introdução à arquitetura e design de sistemas
3. Quatro padrões arquitetônicos de sistemas distribuídos
4. Dropbox em 2012
5. Slack
6. Twitter
7. Reddit
8. Instagram
9. Youtube em 2007
10. Canal sobre design de sistema de um compatriota
11 . outro canal
12. E outro canal
Se você não tem um período difícil, mas a perspectiva de uma entrevista já está aparecendo no horizonte, a tática mais correta seria ler / olhar constantemente algo em segundo plano sobre o assunto de grandes sistemas. O mesmo acontece com os quebra-cabeças algorítmicos: é melhor resolvê-los periodicamente e estar sempre em boa forma do que tentar dominar todo o litcode no fim de semana anterior à entrevista. No entanto, a preparação intensiva para a seção arquitetônica em pouco tempo me tornou um especialista muito melhor.