Préparer l'entrevue de conception de système

1. Bienvenue dans ce cours !: Bonjour les gars et bienvenue dans ce cours sur la préparation de l'entretien de conception du système. m'appelle Alex et je suis ingénieur logiciel, le test est passé et je donne également entretiens de conception de systèmes pendant mon séjour dans des sociétés de logiciels. Lorsque j'ai entendu parler de la possibilité de créer un cours pour plus d'explications sur ces entretiens complexes de type II étais très impatient d'en développer un. Ce cours sera structuré en quatre leçons qui contiennent des étapes pratiques à suivre afin de comprendre exactement ce que les intervieweurs attendront avec impatience lors de la planification de ces types d'entretien que vous allez d'abord évoluer, vous présenter ce qu'est la conception du système. Ensuite, nous examinerons le modèle qui fonctionne lorsqu' il s'agit de résoudre toute question d'entretien de conception de système. Après cela, nous allons également résoudre deux des questions d'entretien les plus courantes dans ce domaine, concevant une nouvelle URL, service de raccourcissement et un système de partage de photos. Si vous souhaitez améliorer vos compétences en entrevue d'ingénieur logiciel, envisagez ce cours pour vous. n'y a pas d'autres exigences qu'une connexion Internet S pour le projet de cette classe, ce sera extrêmement pratique et vous devrez suivre les étapes présentées dans le modèle de cours. Vous pouvez donc commencer votre parcours de résolution de questions d' entrevue de conception de systèmes. Nous avons pensé que c'était dit, je pense que nous sommes prêts. voit dans la première leçon. 2. Qu'est-ce que la conception de système ?: Bonjour les gars et bienvenue dans le système. Vous lui avez dit un tutoriel interviewé. Dans cette conférence, nous allons discuter de ce qu' est exactement la conception du système, ce qui est censé être un entretien de conception de système. Nous allons également examiner certaines bonnes pratiques générales lorsqu'il s' agit de votre propre entretien de conception de système. Vous les placez peut-être en position où vous tentez décrocher un emploi pour une entreprise d' ingénierie logicielle. Et vous avez entendu les deux, je vais avoir une entrevue de conception de système ainsi que des entretiens plus techniques où vous êtes censé enduire. En général, dans les entretiens de conception de systèmes, vous n'avez pas vraiment le droit d'enduire. Peut-être juste un peu pour prouver vos points dans certaines parties. Maintenant, commencez avec la définition de ce que le système a conçu la facilité. Il s'agit simplement du processus consistant à définir différents modules, interfaces, composants, ainsi que les données d'un système afin de répondre aux exigences spécifiées dans votre question. Plus récent lors de l'entrevue. Maintenant, le processus de développement du système est en fait le processus que vous allez effectuer à votre travail. Si vous décrochez la position de développeur, où vous allez réellement créer ou modifier le système. Parallèlement aux processus, modèles, méthodologies et pratiques utilisés pour les développer. Mais pour l'instant, la conception du système n'est que le processus de définition des composants. Il s'agit donc essentiellement de ce qui serait nécessaire lorsque vous essayez de développer un projet à partir de zéro. passant à l'entrevue à part cet entretien de conception de système que vous auriez peut-être mené dans le seul but de permettre aux candidats qui l' acceptent. Comme peut-être des programmeurs, mais il peut s' agir aussi d'ingénieurs ou de designers. L'occasion de prouver leur expertise dans le domaine auquel ils postulent. L'application tangible des connaissances dans résolution d'un problème réel auquel l'entreprise pourrait être confrontée. Il s'agit donc là encore très gros problèmes et d' ordre général. On vous demandera donc d'implémenter quelque chose comme un chat WhatsApp ou quelque chose du genre. Nous allons également avoir des exemples concrets plus loin dans ce cours. Mais encore une fois, ce sont de gros problèmes et vous devez en parler et réfléchir à la façon dont vous les implémenteriez de manière optimale du point de vue de la complexité temporelle et spatiale. Aujourd'hui, cet entretien de conception de système est également mené plus tard dans le processus d'entretien. Tout d'abord, il se peut que vous receviez un entretien technique où on vous demande de coder un problème réel. Et plus tard dans le processus d' entrevue, DC, vous avez une connaissance préalable de certains sujets et vous pouvez également voir les choses d'un point de vue plus large. Ils vont également vous donner l'entretien de conception du système. Maintenant, cet essai avait pour but de voir à quel point vous travaillez en équipe. Et vous abordez également la résolution d'un problème en utilisant des questions qui sont, comme je l'ai déjà mentionné, ouvertes. Et il suffit d' arriver à la meilleure solution possible. Cet entretien est censé analyser votre traitement, résoudre les problèmes, votre processus de réflexion dans la création et la conception des systèmes pour aider les clients éventuels dans l'entreprise que vous souhaitez intégrer besoins. C'est également l'occasion pour vous montrer au personnel recruteur, soit au responsable ou aux autres développeurs avec lesquels vous passez cette entrevue. Les deux sont précieux pour le membre, en affichant vos compétences de cette manière. Lorsqu'il s'agit de questions d' entrevue et de réponses dans la conception du système, elles sont généralement très ambiguës. Et c'est simplement pour permettre la possibilité de démontrer vos qualifications. Mais vous n'avez pas besoin de vous précipiter pour donner une réponse qui pourrait être erronée ou même pas erronée, mais pas suffisamment documentée. Vous vous rencontrez également pour poser des questions avant répondre à leur question dans le but de restreindre la portée. Donnez-vous une direction pour clarifier également les explications. Il s'agissait d' une présentation générale d' un entretien de conception de système. Au cours de la prochaine conférence, nous allons discuter un peu façon dont nous pouvons aborder chaque question d' entretien de conception de système. Il y a un processus en quatre étapes qui a été documenté pour fonctionner, tournant pour y jeter un coup d'œil également. Mais pour l'instant, je vous remercie beaucoup rester avec moi jusqu'à la fin de cette conférence. Et j'ai hâte de vous voir dans le prochain. 3. Un modèle pour toute question: Bonjour les gars et bienvenue dans le tutoriel de l' entretien de conception du système. Dans cette conférence, nous allons examiner quelques étapes que nous pourrions utiliser dans un modèle lorsque nous recevons une question de conception système lors d'une entrevue. Ce moment temporaire dont le moment est sur le point de parler est une taille unique qui convient à tous les types de modèles lorsqu'il s'agit de questions d' entrevue de conception du système, il y a juste quelques étapes que vous devez vous assurer que vous répondez à une question d' entretien de conception système. Pour commencer avec ce modèle, la première chose à partager lorsque l'on vous pose la question c'est que vous le comprenez parfaitement. Nous devons donc comprendre ce problème. Ils ont besoin que vous résolviez et établissiez la portée de la conception dont vous allez parler. C'est la partie où vous devez poser des questions juste après avoir donné tous les détails sur les questions. Vous devrez également définir toutes les contraintes susceptibles d'apparaître. Vous n'avez pas besoin de vous précipiter pour essayer de résoudre le problème avant d'avoir tous les faits et d'avoir d'autres choses qui pourraient ne pas vous être claires par l'intervieweur. La prochaine étape consisterait à proposer une conception de haut niveau. Je dis que vous n'avez pas besoin de vous lancer dans la mise en œuvre sans le confirmer. L'approche à laquelle vous envisagez répond réellement à toutes les contraintes qu'ils souhaitent. Vous pouvez donc proposer une approche qui, selon vous est la meilleure pour résoudre le problème de conception du système. Voyez comment ils réagissent à votre approche avant de vous lancer dans la mise en œuvre même si vous entrez dans les détails de chaque partie de votre proposition. Maintenant, la troisième partie est en fait faite en prenant le plus de temps du mode, qui est le design Deep Dive. Cela se produit une fois que vous avez validé auprès votre intervieweur que vous êtes sur la bonne voie, vous le savez, à ce stade, il vous suffit d'entrer dans tous les détails de la demande résoudre ce que vous avez trouvé. Et c'est là que vous devez avoir une compréhension approfondie et un vocabulaire approfondis de la conception des systèmes. Et lors de cette plongée profonde de conception, il y a encore beaucoup d'étapes, et commencent à plonger en profondeur. La première question que vous devez poser concerne les exigences. Et les exigences peuvent être fonctionnelles ou non fonctionnelles. Les exigences fonctionnelles ne sont que des fonctionnalités que le problème que vous résolvez fournit aux utilisateurs. Par exemple, sur vos réseaux sociaux, il existe une fonctionnalité qui vous permet aimer une publication de n'importe quel autre utilisateur. C'est une exigence fonctionnelle. Vous devez établir et passer en revue toutes les exigences fonctionnelles avec vos intervieweurs par cours, les énumérer et valider leur importance. Maintenant, les exigences peuvent également être infonctionnelles, et il peut y avoir quelques éléments comme la latence, qui est le temps de réponse de l'interaction de l'utilisateur. Fiabilité, ce qui signifie qu' il n'y aura aucune perte de données. La cohérence, ce qui signifie que la haute disponibilité. Maintenant, deux choses que vous devez également garder à l'esprit lorsque vous essayez de concevoir vos composants. Vous devez les fabriquer. Tout d'abord, tolérant les pannes, ce qui signifie que votre système est opérationnel en tout temps, même s'il peut y avoir des erreurs ou des erreurs de base de données. Et ils doivent aussi être des maladies évolutives. Un autre fait important, évolutif, signifie simplement que vous devez gérer la quantité croissante de trafic sur votre système. J'y vais. De plus, à la deuxième partie de ce design Deep Dive. Outre les exigences, vous devez également effectuer une estimation du stockage basée sur la modalité des données, il vous suffit de donner une estimation approximative de la quantité de données à stocker. Vous devez également réfléchir au nombre de demandes, au service que vous fournissez et au ratio de lecture/écriture. Après avoir parlé de toutes ces estimations de stockage, vous devez penser à une conception de base de données. Ici, les actions que vous êtes utilisateur peuvent effectuer pour interagir avec votre système sont en cours. Vous pouvez également réfléchir ici au type de base de données que vous allez utiliser et à la raison pour laquelle vous pouvez opter pour SQL, NoSQL, etc. Il vous suffit de discuter de chaque option et réfléchir à celle qui convient le mieux à votre solution. Ensuite, une quatrième étape consisterait à lancer une conception de base de haut niveau, où vous pouvez écrire sur les clients, les serveurs et la base de données. Et à partir de cette conception de base, vous pouvez en outre entrer dans détails et isoler les services, partitionner les données évoquées sur la mise en cache, ainsi que la réplication des services et bases de données, même l'équilibrage de charge et les files d'attente de messages. Si cela correspond à votre problème spécifique. Il y a bien sûr optionnel d'autres choses auxquelles vous pouvez penser en fonction du problème qui vous est donné, qui peut être le chiffrement de certains messages ou mots de passe. Une télémétrie qui vous permet de garder trace des choses qui sont le plus utilisées dans votre application. Certains services de découverte de services API Gateway et également d service analyse qui analyse les demandes et la bêta de l'utilisateur. Et après cette conception en profondeur, la dernière étape, vous devez prendre cela pour se terminer, qui signifie qu'avec la conception donnée, pour construire. Si cela semble raisonnable, vous pouvez penser à identifier certains goulots d'étranglement et les domaines d' amélioration et en parler un peu. Il s'agit de la structure générale que vous devez garder à l'esprit avant commencer votre entretien de conception du système sans même être confronté au problème. Dans certaines conférences futures, nous allons examiner des questions spécifiques d' entrevue de conception de système telles que la conception du petit système d'URL, moteurs de recherche, des lecteurs partagés , etc. Je peux voir comment j' applique toutes ces étapes à partir de ce modèle exact, mon approche lors de la résolution de problèmes de DC. Si cela vous semble intéressant, j'ai hâte de vous voir lors des prochaines conférences. Merci beaucoup d'être resté avec moi jusqu'à la fin de celle-ci. 4. Le service de raccourcissement des URL: Bonjour les gars et bienvenue dans le tutoriel de l' entretien de conception du système. Dans cette conférence, nous allons discuter d' un problème célèbre souvent évoqué dans ce type d'entretiens. Plus précisément, la conception d'un nouveau service de raccourcissement d'URL. Comme par exemple, vous avez peut-être vu un petit point d' URL L et ainsi de suite. Dans cette conférence, je vais passer en revue tous les aspects que vous devez prendre en compte lorsque S porte ce sujet dans un entretien de conception de système. Et après avoir regardé cette conférence, vous allez savoir comment répondre à cette question. Mais non seulement cela, vous saurez également comment aborder des études de problèmes similaires. Parce qu'en résolvant ce problème, nous allons également respecter le modèle que nous devrions utiliser pour toute question de conception d' entretien système qui nous est posée. commençant par ce problème d' entretien, nous devons concevoir, comme je l'ai dit, un service de raccourcissement d'URL, comme de minuscules URL. Et cette surface fournira, bien sûr, lyse courte, la direction rouge des URL trop longues. Maintenant, la difficulté de l'entretien de conception du système est assez basique et elle est souvent la plus importante dans l'entretien de conception de système. Il est donc très important que vous sachiez comment résoudre ce problème. La première chose dont nous devons discuter est pourquoi devons-nous raccourcir l'URL ? Voici plusieurs raisons et pourquoi nous en aurions besoin. Tout d'abord, ils économisent beaucoup d'espace lorsqu'ils sont affichés, prédisent le message, etc. De plus, si vous voulez les taper à partir de votre propre clavier, vous êtes moins enclin à commettre des erreurs lorsque vous les tapez. Il est également utilisé pour optimiser les liens entre les appareils et mesurer les performances des publicités. La deuxième chose que nous devons aborder concerne les exigences et les objectifs de notre système que nous devons concevoir. Lorsque je me pose cette question, je vous rappelle ici que lorsque vous êtes dans une question d' entretien de conception de système, ainsi que d'autres types d'entretiens. Et on vous pose des questions. Vous devez clarifier toutes les exigences au début. Avant d'essayer de répondre à votre problème. Vous devez poser la question appelée pour trouver la portée exacte du système que vous êtes intervieweur à l'esprit, en vous basant sur les fonctionnalités que cette petite surface URL devrait fournir aux utilisateurs finaux de service. Nous les avons divisées en deux catégories principales d'exigences, qui sont fonctionnelles et non fonctionnelles. Lorsque nous réfléchissons aux exigences fonctionnelles, nous pouvons penser à donner une URL à notre service et à pouvoir générer un retour plus court et unique. Et c'est ce qu'on appelle le lien court. Ce lien fourni par notre service doit également être suffisamment court pour être facilement copié et collé. Et nous allons discuter plus tard de ce que signifie assez court et nous nous sommes également mis d'accord sur ce terme. Maintenant, la deuxième exigence fonctionnelle peut être que l'utilisateur puisse choisir prochainement une personnalisation pour ses URL. Donc, s'ils ne veulent pas un produit aléatoirement par notre surface, ils devraient également pouvoir choisir l'une des leurs. Ces liens fournis par notre surface devraient également avoir une durée après la mort. Ils doivent être supprimés et expirer. Sinon, notre base de données déborderait à un moment donné si vous continuez à y avoir ces liens. Enfin, l'accès des utilisateurs à un lien court doit bien entendu être lu vers le lien original que représente le lien court. Il existe également des exigences non fonctionnelles pour le service de raccourcissement d'URL, à savoir que la direction rouge doit se produire en temps réel sans aucune latence. Parce que imaginez que vous voudriez cliquer un peu sur le lien L-Y et que le chargement prendra une éternité. Vous étiez un lien réel auquel vous souhaitez accéder et qui ne serait pas bon du tout. Et aussi ennuyeux. Une autre exigence non fonctionnelle serait que le lien raccourci fourni ne soit ni devinable ni prévisible par un utilisateur éventuel malveillant. Les dernières exigences non fonctionnelles les plus importantes. Ce serait que notre système, notre service devrait être hautement disponible. Parce que s'il était en panne, toute la redirection d'URL est qu'elle conduirait bien sûr, en bas. Certaines exigences supplémentaires ne peuvent pas être que notre service soit accessible aux API. Ainsi, les tiers peuvent faire une demande réelle à nos points de terminaison et obtenir une URL raccourcie en réponse si la demande est correcte. De plus, quelques analyses que nous pourrons faire avec ce citronnier. Et ils devraient concerner le nombre de fois où la Résurrection s'est produite et aussi le plus souvent où la direction est liée, l'accès et des choses comme ça. Après avoir discuté de toutes ces exigences et coûts du système, nous pouvons passer au troisième, l'estimation de la capacité que le service devrait avoir et aussi la contrainte à battre. Donc, lorsque nous pensons au service que nous allons mettre en œuvre, il sera bien sûr lu lourdement. En effet, de nombreuses demandes de direction rouge comparativement au raccourcissement d'URL seront disponibles. Et nous pouvons supposer un rapport d'environ 90 pour un entre lecture et écriture. Parce que si vous y réfléchissez, vous ne générez le lien qu'une seule fois, mais bien sûr, il sera lu beaucoup plus d'une fois. Maintenant, les estimations du trafic pour le service, nous pouvons supposer que nous allons avoir plus 100 ou 500 millions de nouvelles raccourcissements d'URL par mois créés. Donc, 500 millions d'URL sont peut-être un service de tour. Avec notre pourcentage de lecture/écriture, nous pouvons nous attendre à environ 50 milliards d'érections rouges au cours de ce mois. Nous pouvons également penser à des requêtes par seconde pour notre système juste pour éviter que notre base de données ne se bloque. Mais en dehors de cela, nous devons également examiner les estimations du stockage. Ici, nous pouvons encore faire des estimations. Supposons que nous stockons toutes les demandes de raccourcissement d'URL pendant cinq ans. Étant donné que nous disposons de 500 millions de nouvelles URL et d' objets B et D que nous prévoyons stocker , ce sera environ 30 milliards de dollars. En supposant qu'ils aient pris entre 400 et 500 octets chacun, nous aurons besoin d' environ 15 téraoctets pour stocker l'ensemble de nos données. Nous devons également réfléchir aux estimations de la bande passante, pas seulement à l' estimation du stockage, nous pouvons nous attendre à environ 200 à 300 nouvelles URL chaque seconde. Et c'est bien sûr un top. Nous allons voir le haut de cette gamme. Ainsi, le total des données entrantes pour notre service serait environ 500 octets par demande , deux ou 300 nouvelles URL et B seconde, soit environ 100 à 200 kilo-octets par seconde. Une demande de lecture. Comme chaque seconde, nous prévoyons que 20 à 30 000 URL sont déjà orientées, le total des données sortantes sera d' environ dix mégaoctets par seconde. Nous pouvons également examiner une estimation de la mémoire. Et si nous voulons attraper certaines de nos URL courtes les plus utilisées qui sont très SH a dit x. Eh bien, nous pouvons examiner un peu la règle 8020. Cela signifie que 20 % de nos URL généreront 80 % du trafic. Donc, 20 % de nos URL courtes générées seront les plus chaudes. Et à court terme, nous pouvons constater que si nous avons 20 à 30 000 demandes par seconde, nous recevrons environ 1,7 à 8 milliards de demandes par jour. Pour en capturer 20 %, nous aurons besoin d'environ 170 gigaoctets de mémoire. Comme vous l'avez vu dans mon approche, la partie de l' estimation de la capacité et contraintes doit être très simple en réfléchissant à la limite et en estiment la capacité réelle et la bande passante Il va être pris par surface mise en œuvre. J'ai dit que nous pouvions également examiner certaines API et discuter de cette partie. Nous pouvons mettre à disposition certains points de terminaison que notre service va fournir à des tiers qui souhaitaient accéder à notre affichage de service, faire des demandes à nos points de terminaison et revenir en tant que répondre à l'URL raccourcie. Par exemple, nous pouvons avoir un point de terminaison appelé « créer l'URL ». Et il peut prendre l' URL d'origine comme paramètre de chaîne, qui est bien sûr l'URL d'origine que vous souhaitez raccourcir. Et aussi une sorte de clé associée à la clé développeur API d'un compte. Nous savons donc qui fait ces demandes et nous avons une certaine sécurité dans ces parties. Comme je l'ai déjà dit, ce point final, nous retournerions bien sûr l'insertion réussie. Il va bien sûr renvoyer une chaîne avec l'URL raccourcie si la demande est faite. Eh bien, et si ce n'est pas le cas, peut-être un code d'erreur, nous pouvons également avoir un point de terminaison d'URL de suppression. Ce qui est important, vous pouvez également le mentionner. Nous devons également réfléchir à la façon de prévenir les abus. Si nous exposons une API parce qu' un utilisateur malveillant pourrait vous mettre hors service et détruire vos services s'il met une URL olive c'est la conception actuelle et remplit votre base de données. Nous pouvons imposer ici une certaine limite à la clé développeur API. Il peut être limité à un certain nombre de créations d'URL qui disent dix ou 20 jours ou quelque chose du genre. La prochaine étape consisterait à réfléchir à la conception et au schéma de la base de données. La définition du schéma dans les premiers stades de l'entretien vous aiderait vraiment à comprendre le flux entre les composants vous guiderait vers un partitionnement ultérieur des données. Maintenant, certaines observations ici seraient que nous devons stocker des milliards de dossiers pour les services. Nous allons avoir beaucoup d'URL raccourcies. Mais ces objets vont être très petits, comme je l'ai dit, 500 kilo-octets. n'y a aucune relation entre les enregistrements. Donc, à part le stockage des utilisateurs qui ont créé cette URL, vous êtes à peu près libre de faire ce que nous voulons ici. Et une autre observation concernant la conception de la base de données et pertinente ici est que notre service va être très lourd sur la partie rouge. Nous allons avoir besoin, comme je l'ai dit, de deux tables, une pour stocker les informations sur les mappages d'URL et l'autre pour les données de l'utilisateur, qui a créé le lien court. Puisque nous prévoyons stocker beaucoup de rangées. Et nous n'avons pas non plus besoin de maintenir une relation entre les objets. Maintenant, le type de choix SQL serait très bon ici car il est également très facile à mettre à l'échelle. Nous pouvons donc regarder quelque chose comme Dynamo DB. Je suis venu ici au fur et à mesure que vous résolvez, nous devons créer le schéma de base de données lors d'une interview et réfléchir également au type de base de données à utiliser et suggérer une à partir de vos propres connaissances. La sixième étape sera la conception et l'algorithme de base du système. Nous allons donc nous lancer dans la mise en œuvre de la façon dont notre service va fonctionner en coulisses. Le problème que nous résolvons ici est de générer la clé unique raccourcie qui sera mappée à un SIC d'URL de plus en plus grand. Dans cette situation, nous avons deux approches. Nous pouvons générer ces clés de ligne avec un service de génération de clés. Et il va générer des chaînes aléatoires de six lettres préalable et les stocker dans une nouvelle base de données. Chaque fois que nous voulons raccourcir l'URL ici, nous pouvons en prendre une qui est déjà générée par la surface et ses années. Cette approche est très simple et rapide, mais parce que nous n'encodons pas l'URL, avons donc pas à nous soucier de la duplication ou des collusions. Le service de la génération de clés va s' assurer que toutes les clés seront uniques. Nous devons également garder à l'esprit certains problèmes de concurrence ici, car dès qu'une clé est utilisée, elle doit être marquée dans notre base de données pour s'assurer qu' elle ne sera plus utilisée. Et s'il existe plusieurs serveurs qui lisent ces clés simultanément, vous pouvez obtenir un scénario dans lequel deux services ou plus ont essayé de lire à partir de la base de données, même si, depuis le plus haut jusqu' au service points de terminaison, ce serait très moins probable. Les serveurs peuvent désormais utiliser ces systèmes de génération pour lire et saisir des chapiteaux dans une base de données. Et ils peuvent utiliser deux tables pour ranger les clés. Un pour les clés réelles qui ne sont pas encore utilisées, et l'autre pour les clés déjà utilisées. Et dès que ce service de génération donnera la clé à l'un des serveurs, mangez-les et déplacez-les sur la table. Nous devons également penser ici, si notre système de génération, étant le système unique de l'ensemble de notre service, ne serait-il pas mauvais s'il mourrait ? Et c'est un très bon point car nous avons besoin d' un réplica de secours, ce système de génération afin d'avoir un serveur de secours capable de prendre le relais pour les générer, fournir facilement quelque chose arrive à une approche primaire. Maintenant, une autre approche ici, autre dégénérescence morte des clés avec le service. Permet également de coder le codage URL réel. Une URL réelle peut être réalisée en calculant un hachage unique. Soit si nous parlons de la photo 250 places ou des cinq vides, et que nous pouvons hacher l' URL donnée avec ces algorithmes, ces hachages peuvent être codés pour affichage. Une question raisonnable à cette approche serait quelle serait la taille de la clé abrégée ? Il peut y avoir six à 20 caractères égaux, mais ce serait une clé assez longue. Nous pouvons utiliser le codage base 64. Et si nous allons utiliser des touches de six lettres, il faudra environ 64 à la puissance de six chaînes possibles. Si nous générons huit lettres de clés longues, nous aurons environ 280 billions de chaînes possibles. Mais pour notre système, le numéro de lettre serait assez élevé. Et nous pouvons supposer que six lettres suffisent pour notre nombre d'URL. Maintenant, si nous utilisons l'algorithme MD5 comme fonction de hachage, il fournira, comme vous le savez peut-être déjà, valeurs de hachage de 128 bits. Après le codage en base 64, nous obtiendrons une chaîne comportant plus de 21 caractères. Nous ne disposons désormais que de six ou huit caractères par touche courte. Comment allons-nous alors choisir notre clé ? Eh bien, nous pouvons prendre les premières lettres, mais cela peut entraîner la duplication des clés. Et pour résoudre ce problème, nous pouvons choisir de mettre d'autres caractères hors de l'encodage ou de les échanger entre eux pour éviter complètement ce problème. Nous pouvons également, après avoir donné la solution lors d'une entrevue, réfléchir à certains problèmes avec notre solution, si cela peut s'avérer ne pas être à l'épreuve des balles et que ces différents problèmes viennent de vous et non de la intervieweur. Vous obtiendrez probablement des points supplémentaires car vous serez un employé éventuel plus conscient. Les différents tissus avec l'encodage d'une URL réelle à l'aide d'un hashtag. La solution unique peut être que si plusieurs utilisateurs entrent la même URL, ils peuvent obtenir la même URL raccourcie. Le problème de concurrence est que c'était le cas B, la dernière approche également. Mais en voici un autre. Que se passe-t-il si des parties de l' URL sont codées ? Les solutions de contournement ici encore, l'ajout d'un numéro de séquence croissant à chaque URL d'entrée pour la rendre unique et générer son hachage. Une autre solution pourrait consister à ajouter l'ID utilisateur, qui doit être unique à l'URL d'entrée. Si l'utilisateur ne s'est pas connecté ici, cela pourrait poser problème car nous en aurions besoin pour confirmer l' unicité de la clé. Même si après toutes ces mesures que nous avons prises pour nous assurer que rien ne peut se produire, nous avons toujours un conflit. Nous pouvons continuer à générer la clé jusqu'à ce que nous obtenions la clé unique. Conclure le système de base, concevez une partie d'algorithme. La deuxième partie serait le partitionnement et la réplication des données de notre service. Pour étendre notre base de données, nous devons la partitionner afin qu'elle puisse stocker plus d'informations. Nous avons besoin d'environ des milliards d' entrées dans notre base de données. Et ici, nous pouvons jeter un coup d'œil aux deux types de partitionnement qui existent, à savoir la clé et le partitionnement basé sur le hachage. commençant par les URL du portail de partitionnement basé sur la plage dans des partitions distinctes basées sur les clés de hachage, caractères ou même l'un d'entre eux. Nous pouvons donc enregistrer toutes les URL commençant par exemple, blé ou lettre A dans une partition, et sauvegarder celles qui commencent par la lettre B dans une autre, et ainsi de suite. Et en regardant par contraste le partitionnement basé sur le hachage dans ce schéma, nous pouvons prendre le hachage de l'objet que nous stockons, puis calculer en fonction de la partition à utiliser. Dans notre cas, nous pouvons prendre le hachage de la clé ou le raccourcissement pour déterminer la partition laquelle nous allons démarrer cette URL spécifique. La prochaine chose à laquelle nous devons réfléchir lorsque abordons le problème de conception du système est la partie cash. Nous pouvons donc détecter les URL fréquemment consultées comme nous l'avons déjà suggéré précédemment. Et nous pouvons utiliser n'importe quelle solution d'étagère existante par memcached par exemple. Mais nous pouvons également stocker des URL complètes. Et ce faisant, stockez l'URL complète de leurs hachages respectifs dans leur surfeur dévoué. Dans cette approche, avant de penser, le stockage principal peut rapidement vérifier si le cache possède déjà l'URL de conception. Et ainsi, un service plus optimal. Nous devons également réfléchir ici à quantité de mémoire cache que nous devrions disposer. Nous pouvons donc démarrer. Environ 20 % du trafic quotidien et en fonction des habitudes d'utilisation du client, ajustent en outre le nombre de requêtes de serveurs dont nous avons besoin. Comme on l'a estimé ci-dessus, nous avons besoin d' environ 170 gigaoctets de mémoire pour encaisser 20 % du trafic. Puisqu'un service moderne peut contenir 256 gigaoctets de mémoire, il peut facilement insérer toute l' argent dans une seule machine. s'agissait de la partie mise en cache. Nous pouvons également penser à l' équilibreur de charge de notre système, ce qui est assez simple. Nous pouvons penser à ajouter cette couche d'équilibrage de charge à trois endroits. Et ce serait entre les clients et les serveurs d'applications, ainsi qu'entre les serveurs d' applications, les serveurs base de données et les serveurs de cache. Passons à la question de la danse à laquelle nous devons réfléchir lorsque nous avons question de l' entretien de conception de systèmes la question de l' entretien de conception de systèmes, c'est la purge ou le nettoyage de la base de données. Bien sûr, l'entrée ne devrait pas rester éternellement dans notre base de données car elle la remplirait et déborderait provoquant un crash. Epoque. Y a-t-il un délai d'expiration spécifié ? Que devrait-il advenir du lien ? Eh bien, si nous choisissons de rechercher continuellement des expériences pour les supprimer, cela exercerait également beaucoup de pression sur notre base de données. Nous pouvons donc supprimer lentement les liens expirés en effectuant un nettoyage paresseux. Et la façon dont notre service s'assurera que seuls les liens expirés seront supprimés avec B lorsque l'utilisateur essaye d' accéder au lien inspiré, nous les supprimons en leur faisant le code d' entrée à l'utilisateur. De cette façon, la suppression de toutes les URL n'a pas expiré en même temps et risque de planter la base de données. Nous pouvons également disposer d'un délai d'expiration par défaut pour chaque lien en ce qui concerne cet aspect. Enfin, nous devons également garder à l'esprit que l'arborescence des limites, qui devrait répondre à certaines questions comme le nombre de fois l'URL courte a été utilisée. Quel était l'emplacement de l'utilisateur ? Quelles seraient la date et l' heure de l'accès, etc. Partie sécurité et autorisations, qui est une autre partie importante. Nous pouvons stocker le niveau d'autorisation avec chaque URL de la base de données publique ou privée. Pour les personnes privées, nous pouvons également créer une table distincte pour stocker des identifiants utilisateur disposant des autorisations nécessaires pour voir cette URL spécifique. Bien sûr, s'il ne dispose pas de cette autorisation, notre point de terminaison ou x se trouve dans l'URL courte, peut renvoyer un HTTP pour un code unique, ce qui signifie qu'il n'y a pas assez d'axe. Bien sûr. C'était avant tout les angles que vous devez garder à l'esprit lorsque abordez une solution à la question de surface d'URL raccourcie dans une révision de la conception du système. J'espère que vous avez vraiment tiré quelque chose de cette conférence. Et je vous remercie beaucoup rester avec moi jusqu' à la fin. J'ai également hâte de vous voir dans le prochain. 5. L'application de partage de photos: Bonjour les gars et bienvenue dans le tutoriel de l' entretien de conception du système où nous comprenons comment passer un entretien composé de questions de signe C3b. Dans cette conférence, nous allons discuter un autre problème très courant qui est donné à ces types d'entretiens et examiner exactement comment les résoudre afin de réussir, comme je l'ai dit, l'entretien. Le problème que nous n' allons pas aborder dans cette conférence est la conception d'un service de partage de photos. Ici, les utilisateurs peuvent télécharger photos pour les partager avec d'autres utilisateurs. Et bien sûr, certains services similaires peuvent être Flickr ou certaines plateformes de médias sociaux, même s'ils ont plus de fonctionnalités intégrées à eux. Tout d'abord, lorsque j' aborderai ce problème, je vais utiliser le modèle général adapté à toute question de conception de système qui peut être posée lors d'une interview dont j'ai parlé lors d'une conférence précédente. Et la première étape après avoir bien compris la question et poser toute autre demande de requête que vous pourriez avoir de la part de votre intervieweur consiste à définir les exigences et les objectifs de le système dont vous allez parler. Lors de la conception de notre application de partage de photos, nous aimerions avoir certaines exigences fonctionnelles, notamment qu' un utilisateur puisse suivre d'autres utilisateurs disposant d'un compte sur cette plateforme. L'utilisateur peut également effectuer certaines recherches qui peuvent être basées sur les photos partagées. Avez-vous recherché peut également télécharger des photos elles-mêmes à partir de leur compte. Et le système que nous allons mettre en œuvre devrait également générer et afficher une sorte de flux d' actualités où un utilisateur, lorsqu'il ouvre l'application, verra les meilleures photos des personnes qu'il a combattues arcs. Comme je l'ai dit, il s'agit là des exigences fonctionnelles, mais nous devons également réfléchir aux exigences fonctionnelles. L' exigence non fonctionnelle numéro un doit être que le système soit très fiable, ce qui signifie qu'une fois que l'utilisateur téléchargé une photo sur notre surface, la photo ne sera pas perdue. Ensuite, notre surface doit être hautement disponible, donc toute question n'est pas autorisée. De plus, nous devrions maintenir notre latence niveau réduit pour la régénération des nouvelles et d'autres choses comme ça. Ce qui signifie le temps pendant lequel l'utilisateur va réellement attendre du démarrage de l'application jusqu' au point où il verra réellement certaines photos d' autres utilisateurs qu'il suit. La première étape est donc terminée. Et nous définissons les exigences et les objectifs du système que nous sommes sur le point de concevoir. Nous pouvons prendre en compte quelques autres considérations de conception. Ici. Nous pouvons commencer par le fait que tous ces services que nous allons mettre en œuvre, il est assez évident que ce sera très lu car la dette nette lorsque les utilisateurs téléchargeront réellement des photos, mais un nombre beaucoup plus élevé d'utilisateurs verra en fait les photos que j'ai vues par d'autres utilisateurs. Vous pouvez le penser, comme vous le pensez lorsque vous publiez une photo sur votre application de médias sociaux. Vous publiez très peu de fois, mais vous voyez en fait beaucoup d' autres fonctionnalités en comparaison pour vous regarder télécharger. C'est pourquoi ce système sera lu lourdement. Du fait que notre service sera lu fort, nous devons nous concentrer sur la récupération. La photo est très rapide. Désormais, les utilisateurs peuvent également télécharger autant de photos que la lumière du jour. C'est donc une chose à garder à l'esprit car nous avons besoin d'une gestion très efficace du stockage de ces photos. Et aussi, je l'ai dit, si un utilisateur télécharge une photo, ce système que nous avons conçu, nous garantissons qu'elle ne sera pas perdue. passés à une estimation et des contraintes quant à la capacité des objets que nous allons stocker. Nous pouvons supposer que nous aurons 100 millions d'utilisateurs avec environ 10 000 utilisateurs actifs par jour et 2 millions de nouvelles photos chaque jour. Ce serait environ 23 nouvelles photos chaque seconde. Et ces calculs que nous allons faire ici ont lieu à ici ont lieu à une date ultérieure où notre service sera largement adopté et couronné de succès. C'est pourquoi vous me voyez briser ces montants très élevés pour ces montants. Des chiffres réels. Maintenant, l'espace total requis pour une journée de photos, comme je l'ai dit, serait d'environ 2 millions parce que nous avions dit que nous aurions 2 millions de nouvelles photos chaque jour. Et nous pouvons penser à la taille moyenne du fichier photo, qui peut être de 100 kilo-octets, soit environ 200 gigaoctets au total pour notre capacité. Maintenant, cela ne prend en compte qu'un jour. Mais que se passe-t-il si nous indiquons l'espace pendant cinq ans, disons ? Eh bien, nous pouvons multiplier 200 par 3655 ans, et nous allons obtenir environ 365 téraoctets, donc 365 téraoctets. Maintenant que nous avons cette estimation de la capacité hors du chemin, nous pouvons penser à la conception du système de haut niveau. Parce qu'à un niveau élevé, nous n'avons besoin que de prendre en charge deux scénarios. Un pour télécharger les photos, c' est-à-dire le flux de travail dans notre service. Et oui, ils voulaient voir ou rechercher ces photos. Le service que nous allons mettre en œuvre doit bien sûr stocker les photos dans une base de données. Et nous allons avoir besoin de serveurs de stockage d'objets ici. En outre, pour le schéma de base de données permettant de stocker ces photos, il sera également discuté dans l'interview. Nous devons garder à l'esprit que nous avons environ trois entités. Un qui sera l'utilisateur, ensuite les photos, puis les utilisateurs qu'il suit. Le schéma peut contenir trois tables. Lorsqu'une photo, qui peut avoir une pièce d'identité avec photo, qui sera la clé primaire. Et puis quelques autres champs comme l'ID utilisateur, qui est bien sûr que l' utilisateur mort l'a posté, qui sera une clé étrangère dans cette table. Un autre champ très important ici sera la date de création, qui sera de type datetime. Et c'est un domaine très important car il va être utile lorsque l'utilisateur ouvrira son fil d'actualité, nous voulions lui obtenir les photos les plus récentes et les plus populaires, mais pour la dernière partie, nous allons être utile lorsque l'utilisateur ouvrira son fil d'actualité, nous voulions lui obtenir les photos les plus récentes et les plus populaires, mais pour la dernière partie, nous allons manger cette région battue champ. Ensuite, nous avons également la table des utilisateurs, qui aura bien sûr une clé primaire d'ID utilisateur. Et puis d'autres données que nous voulions stocker pour lui. Si nous voulons faire du marketing par e-mail, vous pouvez conserver son e-mail. Mais nous avons également besoin du nom, de la date de naissance, la date de chaque compte et peut-être de la dernière connexion. Je réfléchis. Nous aurions également besoin d'une table pour l'utilisateur follow, qui prendrait un champ qui fera tous deux partie de la clé primaire. Et il s'agira bien sûr des identifiants des utilisateurs qui se suivent. Cela tient donc bien sûr compte du scénario où l'utilisateur va dans les deux sens, comme sur Facebook lorsque vous ajoutez un ami. Donc, si vous vous acceptez tous les deux comme un ami, pas comme un Instagram où le suivi peut être unidirectionnel. Vous pouvez donc suivre quelqu'un qui ne vous suivrait pas. Nous n'avons pas ce scénario dans cette discussion uniquement pour que nous puissions le rendre un peu plus simple. Maintenant, l' approche simple pour prendre d' assaut les détecteurs de schéma dont parle les détecteurs serait un MySQL nécessitant évidemment les joints, mais nous pouvons le stocker dans un magasin de valeur de clé distribué pour profiter du les avantages offerts par NoSQL également. Après avoir parlé du schéma de la base de données dans notre entretien, nous devons également prendre une autre estimation de la taille des données. Le D décide donc de l'estimation sur le contient des informations sur les champs qui vont être stockés dans notre base de données. Et nous devons penser aux entiers, aux chaînes, etc. Plus tard, ils seront stockés dans notre base de données. Nous pouvons supposer que chaque requête en entrée et la DateTime dépassent quatre octets. Ainsi, chaque ligne de la table des utilisateurs comptera environ 68 octets. S'il y avait, comme je l'ai déjà compté, environ six champs. Si nous avions, par exemple, 250 millions d'utilisateurs, nous aurons exemple, 250 millions d'utilisateurs, nous aurons besoin d'environ 16 gigaoctets de stockage uniquement pour que la partie de l'utilisateur puisse être stockée avec toutes ses informations dans notre base de données. Mais qu'en est-il des photos ? Ainsi, chaque ligne de la table de photos aura environ 284 octets Cs. Nous avons également un pack de photos, qui sera un graphique var 265 caractères et qui prend 265 caractères, regardez l' entrée de photo qui serait assez longue que celle de l'utilisateur, mais ce serait C'est plutôt normal. Si nous prenons en compte environ 1 million de nouvelles photos téléchargées chaque jour, nous aurons besoin d'environ 200 et 50 mégaoctets de stockage pendant une journée. Et ce sera dans dix ans, environ un téraoctet, presque. Le dernier tableau, chaque utilisateur suit la table. Et si elle se compose de huit octets, nous n'avions que la clé primaire composée de deux intégrales, chacune de quatre octets. Nous pouvons penser à 250 millions d'utilisateurs. Ils peuvent suivre encore 250 millions d'utilisateurs et nous allons rencontrer un autre pétaoctet de stockage supplémentaire pour la table suivie par l' utilisateur. L'espace total requis pour toutes ces tables pour les oreilles, comme je l'ai dit, serait d' environ deux téraoctets, ce qui est vraiment idéal pour une application. Et la surface de ces types. week-end prochain, nous avons également examiné rapidement la conception des composants que nous allons avoir dans ce service. La photo est téléchargée ou lente à droite. Lisez qui va être plus rapide, surtout s'ils sont servis en espèces. téléchargeant, les utilisateurs peuvent consommer connexions de deck disponibles car le téléchargement est un processus lent ce qui signifie que nous ne pouvons pas être servis. L'un ou l'autre des systèmes est occupé par toutes les bonnes demandes. Nous devons garder à l'esprit que ces services Web ont une connexion si nous nous rencontrons avant de concevoir le système. Donc, si vous supposez qu' un serveur Web peut avoir un maximum de 500 connexions à n fois, il peut avoir plus de 500 téléchargements simultanés ou lectures gérées par ce goulot d'étranglement, nous pouvons diviser les lectures et écrit dans des services distincts. Cela nous permettra également à l'avenir de faire évoluer ces opérations de manière indépendante et beaucoup plus facile puisqu'il s'agit de deux entités distinctes. Pour la partie redondance maintenant, perte de fichiers est que j'ai déjà mentionnée, n' est pas une option. Nous pouvons commencer plusieurs copies de chaque fichier comme solution à la dette. Parce que si un dé de stockage, on peut récupérer le quatrième trop fort, l'autre copie. Mais le même principe s'applique également aux autres composants. Donc, si nous voulons avoir la disponibilité d'un système qui serait très vendu, notre système ne mourrait à aucun moment. Nous devons également disposer de répliques du service en cours d'exécution. Les services se sont éteints. Le système reste disponible avec peur, car cette redondance supprime le point de défaillance unique du système. C'est un point très important. Lorsque vous prenez un entretien de conception de système, vous devez penser que si vous implémentez réellement un point d' échec unique La dette S est un inconvénient et elle doit être observée. Et vous devez également trouver une solution de contournement. Si une seule instance des services requis pour l' exécuter à n'importe quel moment, nous pouvons exécuter une copie secondaire redondante du service qui ne dessert aucun trafic, mais elle peut prendre le contrôle après la fatal pour la primaire sourde blanche a un problème. Comme je l'ai dit, il s'agit deux instances du même service qui s'exécutent en production et l'une échoue. Le système peut basculer vers la copie saine. Et cela peut se produire automatiquement ou nécessiter une intervention manuelle, même si vous n'entrez pas dans votre système en panne à un moment donné, vous feriez mieux de l'implémenter et de le récupérer automatiquement. Parce que sinon, vous devez faire observer que votre système est de la gomme, puis intervenir manuellement avec la dette du développeur peut bien sûr par lui-même rediriger le 17e 2D disponible. Nous pouvons également parler du partage des données. Parce que, bien sûr, je pense que de telles quantités de données sont importantes, nous devons les partager d'une manière ou d'une autre. Nous pouvons établir un diagramme sur l'ID utilisateur afin de conserver toutes les photos d'un utilisateur dans la même base de données nette et définie, soit un téraoctets. Vous aurez besoin de quatre graphiques pour stocker environ quatre téraoctets de données. Maintenant, pour les performances et évolutivité, conservez une dizaine d'entre elles. Encore une fois, le système FOR s'agrandit de plus en plus, nous allons pouvoir gérer tout le trafic de dettes. Nous allons devoir trouver le nombre net par utilisateur multiple de dix. Commençons par là. Identifiez de manière unique n'importe quelle photo de notre système. Nous pouvons ajouter ce numéro à la pièce d'identité avec photo, ce qui serait une solution assez simple à cet égard. Comment générer les identifiants photo alors que chaque base de données peut avoir sa propre séquence d'incrémentation automatique pour les identifiants photo ? Et comme nous ajouterons cette idée de la pièce d'identité avec photo nette, elle la rendra unique dans tout notre système. Même si nous avons mis au point ce système de partitionnement, il présente quelques inconvénients. Par exemple, si nous ne pouvons pas stocker toutes les images en surutilisant mon graphique, nous devons les distribuer à plusieurs et causer une maladie plus élevée plus tard. Et aussi, les utilisateurs du cœur doivent être traités différemment car ils sont suivis par beaucoup d' autres utilisateurs et beaucoup de gens. Ils verront leur télécharger les photos et la dette peut causer des problèmes à cet égard. Bien sûr, nous pouvons partitionner autour de la pièce d' identité avec photo et non de l'ID utilisateur, ce qui peut être une autre approche. Parce que si nous sommes généralement ces pièces d'identité avec photo sont en premier, nous pouvons trouver à nouveau le numéro net, le module d'identification avec photo, ce qui signifie qu'ils sont moins de chiffres en gros. Et bien sûr, les problèmes dont nous venons de parler étaient les inconvénients après la première approche auraient été résolus à ce stade. Encore une fois, pour générer les identifiants avec photo, vous ne pouvez pas avoir de séquence auto-incrémentante car vous devez savoir que l'identification avec photo est d'abord définie la solution précise ici pourrait être de dédier une base de données distincte . générer cet ID auto-incrémentant, nous devons également réfléchir beaucoup à l'avenir et fusionner notre croissance du système. Si nous avons un grand nombre de partitions logiques pour accumuler la croissance des données au début, plusieurs partitions logiques à l'intérieur d'une seule base de données physique, de base données CCS, ou nous pouvons avoir plusieurs systèmes de bases de données exécutés dessus. Nous pouvons disposer de bases de données distinctes pour chaque partition logique sur n'importe quel serveur. Chaque fois que nous estimons qu' un serveur de base de données en particulier contient beaucoup de données, nous pouvons créer des partitions logiques sur un autre serveur et conserver un fichier de configuration. Et cela constituerait la seule chose que nous aurions à mettre à jour pour annoncer un éventuel changement. Le classement et la génération de flux d'actualités constituent un autre problème auquel nous sommes confrontés. La façon dont nous allons y faire face. Ou au moins une des façons dont nous pouvons y faire face est de prégénérer le flux américain. Nous pouvons avoir certains serveurs dont leur seule tâche serait de générer des utilisateurs en continu et de les stocker dans une autre table appelée fil d'actualité des utilisateurs. Lorsque l'utilisateur a besoin de cette photo pour une nouvelle suite, nous allons simplement interroger ce tableau et renvoyer les résultats. Leslie, nous devons aussi penser à équilibrage de la trésorerie et de la charge du système car il sera très utilisé un, nous devons introduire un cache pour moi à Data Service pour attraper les lignes de base de données. Cela signifie que les hot folders et les utilisateurs. Nous pouvons utiliser le cas de demande pour enregistrer ces serveurs de données et d'applications Avant d'accéder à la base de données, vous pourrez vérifier rapidement si le cache possède les routes souhaitées. Ici, une approche raisonnable serait la R U, qui est la moins utilisée récemment. Pour la stratégie d'éviction du cache. Nous pouvons construire le Kiersten intégré plus intelligent, utilisant la règle 8020, qui stipule que 280% du volume de photos qui seront lues quotidiennement, nous générerons 80 % du trafic, nous pouvons donc simplement encaisser les 20 % premiers. Il s'agissait donc de toutes les étapes et de données infinies. Je considérerais comme un impuissant lors de l' entretien de conception du système et je recevrais une mise en œuvre de conception de service de partage de photos. Je vous remercie beaucoup de rester avec moi jusqu'à la fin de cette conférence. Et j'ai hâte de vous voir dans le prochain.