Plan
Il est très important de l'avoir. Même si vous faites une erreur quelque part et que vous tournez dans le mauvais sens dans votre raisonnement, l'approche structurée globale fera le jeu de vos mains. Au tout début, vous pouvez modérément émousser et interroger la personne interrogée sur les détails, mais à partir d'un certain point (qui dans mon plan ci-dessous correspond au point 3), vous devriez avoir complètement l'initiative et il vaut mieux ne pas la lâcher jusqu'à la toute fin. Mon plan était quelque chose comme ça:
- Rassemblez une liste des caractéristiques clés et écrivez-les dans le coin du tableau. Cette astuce simple vous aidera à vous souvenir d'une contrainte ou d'une hypothèse importante.
- Comprendre les caractéristiques techniques du système: RPS attendu, plage de temps de réponse acceptable, attentes en termes de cohérence et de fiabilité.
- Créez la solution à une machine la plus simple qui fonctionnera d'une manière ou d'une autre. Il n'est pas nécessaire de commencer avec 20 datacenters à travers le monde, il vaut bien mieux y arriver progressivement.
- Trouvez un point de défaillance unique ou un goulot d'étranglement des performances.
- Offrez une ou plusieurs options pour résoudre le problème, expliquez clairement les avantages et les inconvénients de chacune d'elles
- Choisissez l'une des options et passez à l'étape 4, s'il reste du temps, et si cela se termine, passez à l'élément suivant
- Estimez la taille du stockage, le nombre de serveurs, la bande passante du réseau, notez soigneusement tout cela
- Bonus: parler des fonctionnalités supplémentaires, de la mise en œuvre du ML, des métriques produit, des expériences
Le contrôle du temps est très important. J'ai essayé de passer 5 à 10 minutes sur les deux premiers points et 5 minutes sur les deux derniers.
Les compromis
Ils ont besoin d'être prononcés, même s'ils semblent évidents. Après avoir introduit une nouvelle pièce, il est important de dire quelque chose comme "nous avons ajouté un nouvel élément, cela résoudra tel ou tel problème, mais nous paierons pour cela". Les compromis peuvent être quelque chose comme ceci:
- Tout nouveau composant système ou une augmentation du nombre de pièces de rechange existantes résout le problème de vitesse de charge / réponse, mais ajoute des maux de tête avec le support et le déploiement.
- Le sharding résout les contraintes de charge et d'espace, mais ajoute des problèmes de re-sharding à l'avenir.
- Le stockage répliqué résout le problème de la charge et de la fiabilité, mais dans le cas des répliques en lecture et en écriture, il fait penser aux valeurs pourries et à l'opposition de disponibilité et de cohérence
- Le cache résout le problème de charge, mais vous fait penser aux valeurs rances et à la cohérence du cache.
- Votre propre solution peut être facilement modifiée et optimisée pour vos besoins, mais vous devez d'abord l'écrire.
- La bonne chose à propos de la solution existante est qu'elle existe déjà, mais vous devez la comprendre.
Nombres
Tout le monde connaît les nombres de latence que tout programmeur devrait connaître , mais les nombres sur le lien, à mon avis, ne sont pas structurés de la manière la plus pratique et je les ai reformatés dans le processus de préparation pour faciliter la mémorisation.
En fin de compte, ce qui suit est important:
- Connaissez le temps passé à lire des données à partir de différents niveaux de caches de processeur, de mémoire, de SSD, de disque dur et de réseau.
- N'oubliez pas le temps des allers-retours à l'intérieur du centre de données et dans le monde, ainsi que la latence minimale qu'une personne perçoit comme un décalage (~ 100 ms).
- Pour pouvoir convertir rapidement des octets en gigaoctets, des nanosecondes en secondes, etc., j'ai développé cette compétence par elle-même dans le processus de pratique.
Entraine toi
J'ai acheté un tableau blanc, pris des services existants et essayé de comprendre comment je les créerais à partir de zéro. J'ai dessiné des diagrammes sur le tableau, déterminé la charge et les ressources nécessaires, recherché les points faibles de ma conception. J'ai aussi de très bons amis avec lesquels nous avons organisé des pseudo-sections et nous nous sommes entraînés les uns sur les autres - ce fut une expérience super enrichissante. Après la pratique, vous pouvez aller en ligne et chercher comment cela est réellement fait, puis réessayer. Après 10 à 20 tours avec différents services, l'illumination s'installe et les parties récurrentes individuelles des systèmes existants commencent à être clairement visibles. Les pièces de rechange peuvent être, par exemple:
- Recherche (de préférence avec la possibilité de mettre à jour l'index en temps réel)
- (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. , .
- ( ). . , , .
- Un grand choix de haute évolutivité
- Eh bien, la ressource la plus importante est vos amis et connaissances qui savent comment leurs systèmes fonctionnent et peuvent vous en parler.
Plusieurs bonnes vidéos et chaînes
1. Évolutivité
2. Introduction à l'architecture et aux entrevues de conception de systèmes
3. Quatre modèles architecturaux de systèmes distribués
4. Dropbox en 2012
5. Slack
6. Twitter
7. Reddit
8. Instagram
9. Youtube en 2007
10. Chaîne sur la conception de systèmes d'un compatriote
11 . une autre chaîne
12. Et une autre chaîne
Si vous n'avez pas un délai difficile, mais que la perspective d'un entretien se profile déjà à l'horizon, la tactique la plus correcte serait de lire / regarder constamment quelque chose en arrière-plan sur le sujet des grands systèmes. Il en va de même avec les énigmes algorithmiques: mieux vaut les résoudre périodiquement et être toujours en forme que d'essayer de maîtriser tout le litcode le week-end précédant l'interview. Cependant, une préparation intensive de la section architecturale en peu de temps a fait de moi un bien meilleur spécialiste.