Web Analytics

system-design-primer

⭐ 318813 stars French by donnemartin

English ∙ 日本語 ∙ 简体中文 ∙ 繁體中文 | العَرَبِيَّة‎ ∙ বাংলা ∙ Português do Brasil ∙ Deutsch ∙ ελληνικά ∙ עברית ∙ Italiano ∙ 한국어 ∙ فارسی ∙ Polski ∙ русский язык ∙ Español ∙ ภาษาไทย ∙ Türkçe ∙ tiếng Việt ∙ Français | Add Translation

Aidez à traduire ce guide !

Le Guide de Conception de Systèmes


Motivation

Apprenez à concevoir des systèmes à grande échelle.
>
Préparez-vous à l'entretien de conception de systèmes.

Apprenez à concevoir des systèmes à grande échelle

Apprendre à concevoir des systèmes évolutifs vous aidera à devenir un meilleur ingénieur.

La conception de systèmes est un sujet vaste. Il existe une énorme quantité de ressources dispersées sur le web concernant les principes de conception de systèmes.

Ce dépôt est une collection organisée de ressources pour vous aider à apprendre à construire des systèmes à grande échelle.

Apprenez de la communauté open source

C'est un projet open source continuellement mis à jour.

Les contributions sont les bienvenues !

Préparez-vous à l'entretien de conception de systèmes

En plus des entretiens de programmation, la conception de systèmes est une composante obligatoire du processus d'entretien technique dans de nombreuses entreprises technologiques.

Exercez-vous sur des questions courantes d’entretien de conception de systèmes et comparez vos résultats avec des solutions exemples : discussions, code et diagrammes.

Sujets supplémentaires pour la préparation à l’entretien :

Flashcards Anki


Les paquets de flashcards Anki fournis utilisent la répétition espacée pour vous aider à retenir les concepts clés de la conception système.

Idéal pour une utilisation en déplacement.

Ressource de codage : Défis de codage interactifs

Vous cherchez des ressources pour vous préparer à l'entretien de codage ?


Découvrez le dépôt frère Interactive Coding Challenges, qui contient un paquet Anki supplémentaire :

Contribution

Apprenez de la communauté.

N'hésitez pas à soumettre des pull requests pour aider à :

Le contenu nécessitant un certain affinage est placé en cours de développement.

Consultez les Lignes directrices de contribution.

Index des sujets de conception de systèmes

Résumés de divers sujets de conception de systèmes, incluant avantages et inconvénients. Tout est un compromis.
Chaque section contient des liens vers des ressources plus approfondies.


Guide d'étude

Sujets suggérés à réviser en fonction de votre calendrier d'entretien (court, moyen, long).

Imgur

Q : Pour les entretiens, dois-je tout savoir ici ?

R : Non, vous n'avez pas besoin de tout savoir ici pour préparer l'entretien.

Ce qui vous est demandé lors d'un entretien dépend de variables telles que :

Les candidats plus expérimentés sont généralement censés en savoir plus sur la conception de systèmes. Les architectes ou chefs d'équipe pourraient être attendus pour en savoir plus que les contributeurs individuels. Les grandes entreprises technologiques ont probablement un ou plusieurs tours d'entretien de conception.

Commencez large et approfondissez quelques domaines. Il est utile de connaître un peu divers sujets clés de la conception de systèmes. Ajustez ce guide en fonction de votre calendrier, de votre expérience, des postes pour lesquels vous passez des entretiens, et des entreprises avec lesquelles vous passez des entretiens.

| | Court | Moyen | Long | |---|---|---|---| | Parcourez les Sujets de conception de systèmes pour obtenir une compréhension large du fonctionnement des systèmes | :+1: | :+1: | :+1: | | Parcourez quelques articles dans les Blogs d’ingénierie des entreprises des entreprises avec lesquelles vous passez des entretiens | :+1: | :+1: | :+1: | | Parcourez quelques Architectures du monde réel | :+1: | :+1: | :+1: | | Révisez Comment aborder une question d’entretien de conception de système | :+1: | :+1: | :+1: | | Travaillez les Questions d’entretien de conception de système avec solutions | Quelques-unes | Beaucoup | La plupart | | Travaillez les Questions d’entretien de conception orientée objet avec solutions | Quelques-unes | Beaucoup | La plupart | | Révisez les Questions d’entretien supplémentaires sur la conception de systèmes | Quelques-unes | Beaucoup | La plupart |

Comment aborder une question d’entretien de conception de système

Comment aborder une question d’entretien de conception de système.

L’entretien de conception de système est une conversation ouverte. Vous êtes censé la diriger.

Vous pouvez utiliser les étapes suivantes pour guider la discussion. Pour aider à solidifier ce processus, travaillez la section Questions d’entretien de conception de système avec solutions en suivant les étapes ci-dessous.

Étape 1 : Définir les cas d’utilisation, contraintes et hypothèses

Recueillez les exigences et délimitez le problème. Posez des questions pour clarifier les cas d’utilisation et les contraintes. Discutez des hypothèses.

Étape 2 : Créer un design de haut niveau

Esquissez un design de haut niveau avec tous les composants importants.

Étape 3 : Concevoir les composants principaux

Plongez dans les détails de chaque composant principal. Par exemple, si on vous demande de concevoir un service de raccourcissement d’URL, discutez :

Étape 4 : Mettre à l’échelle la conception

Identifiez et traitez les goulets d’étranglement, compte tenu des contraintes. Par exemple, avez-vous besoin des éléments suivants pour résoudre les problèmes de scalabilité ?

Discutez des solutions potentielles et des compromis. Tout est compromis. Traitez les goulets d’étranglement en utilisant les principes de conception de systèmes scalables.

Calculs approximatifs

Il se peut qu’on vous demande de faire quelques estimations à la main. Reportez-vous à l’Annexe pour les ressources suivantes :

Source(s) et lectures complémentaires

Consultez les liens suivants pour mieux comprendre à quoi vous attendre :

Questions d'entretien de conception de système avec solutions

Questions courantes d'entretien de conception de système avec discussions, code et diagrammes d'exemple.
>
Solutions liées au contenu dans le dossier solutions/.

| Question | | |---|---| | Concevoir Pastebin.com (ou Bit.ly) | Solution | | Concevoir la timeline et la recherche Twitter (ou le fil d'actualité et la recherche Facebook) | Solution | | Concevoir un robot d'exploration web | Solution | | Concevoir Mint.com | Solution | | Concevoir les structures de données pour un réseau social | Solution | | Concevoir un magasin clé-valeur pour un moteur de recherche | Solution | | Concevoir la fonctionnalité de classement des ventes par catégorie d'Amazon | Solution | | Concevoir un système évolutif pour des millions d'utilisateurs sur AWS | Solution | | Ajouter une question de conception de système | Contribuer |

Concevoir Pastebin.com (ou Bit.ly)

Voir l'exercice et la solution

Imgur

Concevoir la timeline et la recherche Twitter (ou le fil d'actualité et la recherche Facebook)

Voir l'exercice et la solution

Imgur

Concevoir un robot d'exploration web

Voir l'exercice et la solution

Imgur

Design Mint.com

View exercise and solution

Imgur

Design the data structures for a social network

View exercise and solution

Imgur

Design a key-value store for a search engine

View exercise and solution

Imgur

Design Amazon's sales ranking by category feature

View exercise and solution

Imgur

Design a system that scales to millions of users on AWS

View exercise and solution

Imgur

Object-oriented design interview questions with solutions

Common object-oriented design interview questions with sample discussions, code, and diagrams.
>
Solutions linked to content in the solutions/ folder.

>Note: This section is under development

| Question | | |---|---| | Concevoir une table de hachage | Solution | | Concevoir un cache LRU (least recently used) | Solution | | Concevoir un centre d'appels | Solution | | Concevoir un jeu de cartes | Solution | | Concevoir un parking | Solution | | Concevoir un serveur de chat | Solution | | Concevoir un tableau circulaire | Contribuer | | Ajouter une question de conception orientée objet | Contribuer |

Sujets de conception de système : commencez ici

Nouveau en conception de système ?

D'abord, vous aurez besoin d'une compréhension de base des principes courants, apprendre ce qu'ils sont, comment ils sont utilisés, et leurs avantages et inconvénients.

Étape 1 : Revoir la conférence vidéo sur la scalabilité

Conférence sur la scalabilité à Harvard

Étape 2 : Revoir l'article sur la scalabilité

Scalabilité

Étapes suivantes

Ensuite, nous examinerons les compromis de haut niveau :

Gardez à l’esprit que tout est un compromis.

Puis, nous plongerons dans des sujets plus spécifiques tels que DNS, CDN et équilibreurs de charge.

Performance vs scalabilité

Un service est scalable s’il entraîne une augmentation de la performance de manière proportionnelle aux ressources ajoutées. Généralement, augmenter la performance signifie traiter plus d’unités de travail, mais cela peut aussi être pour gérer des unités de travail plus importantes, comme lorsque les jeux de données grandissent.1

Une autre façon de voir la performance vs scalabilité :

Source(s) et lectures complémentaires

Latence vs débit

La latence est le temps nécessaire pour effectuer une action ou produire un résultat.

Le débit est le nombre de ces actions ou résultats par unité de temps.

Généralement, vous devez viser un débit maximal avec une latence acceptable.

Source(s) et lectures complémentaires

Disponibilité vs cohérence

Théorème CAP


Source : Théorème CAP revisité

Dans un système informatique distribué, vous ne pouvez garantir que deux des trois garanties suivantes :

Les réseaux ne sont pas fiables, vous devrez donc supporter la tolérance au partitionnement. Vous devrez faire un compromis logiciel entre cohérence et disponibilité.

#### CP - cohérence et tolérance au partitionnement

Attendre une réponse du nœud partitionné peut entraîner une erreur de délai d’attente. CP est un bon choix si vos besoins métiers nécessitent des lectures et écritures atomiques.

#### AP - disponibilité et tolérance au partitionnement

Les réponses retournent la version des données la plus facilement disponible sur n’importe quel nœud, qui peut ne pas être la plus récente. Les écritures peuvent prendre un certain temps à se propager lorsque le partitionnement est résolu.

AP est un bon choix si le métier doit permettre la cohérence éventuelle ou quand le système doit continuer à fonctionner malgré des erreurs externes.

Source(s) et lectures complémentaires

Modèles de cohérence

Avec plusieurs copies des mêmes données, nous sommes confrontés à des options pour les synchroniser afin que les clients aient une vue cohérente des données. Rappelons la définition de la cohérence dans le théorème CAP - Chaque lecture reçoit la dernière écriture ou une erreur.

Cohérence faible

Après une écriture, les lectures peuvent ou non la voir. Une approche de meilleure tentative est adoptée.

Cette approche se retrouve dans des systèmes comme memcached. La cohérence faible fonctionne bien dans les cas d’utilisation en temps réel tels que VoIP, visioconférence et jeux multijoueurs en temps réel. Par exemple, si vous êtes en appel téléphonique et perdez la réception pendant quelques secondes, lorsque vous récupérez la connexion, vous n’entendez pas ce qui a été dit pendant la perte de connexion.

Cohérence éventuelle

Après une écriture, les lectures la verront finalement (typiquement en quelques millisecondes). Les données sont répliquées de manière asynchrone.

Cette approche est observée dans des systèmes tels que DNS et le courrier électronique. La cohérence éventuelle fonctionne bien dans les systèmes hautement disponibles.

Cohérence forte

Après une écriture, les lectures la verront. Les données sont répliquées de manière synchrone.

Cette approche est observée dans les systèmes de fichiers et les SGBDR. La cohérence forte fonctionne bien dans les systèmes nécessitant des transactions.

Source(s) et lectures complémentaires

Modèles de disponibilité

Il existe deux modèles complémentaires pour supporter une haute disponibilité : basculement et réplication.

Basculement

#### Actif-passif

Avec le basculement actif-passif, des signaux de vie sont envoyés entre le serveur actif et le serveur passif en attente. Si le signal de vie est interrompu, le serveur passif prend l'adresse IP de l'actif et reprend le service.

La durée d'indisponibilité est déterminée par le fait que le serveur passif fonctionne déjà en veille « chaude » ou s'il doit démarrer depuis une veille « froide ». Seul le serveur actif gère le trafic.

Le basculement actif-passif peut aussi être appelé basculement maître-esclave.

#### Actif-actif

En actif-actif, les deux serveurs gèrent le trafic, répartissant la charge entre eux.

Si les serveurs sont exposés au public, le DNS doit connaître les adresses IP publiques des deux serveurs. Si les serveurs sont internes, la logique applicative doit connaître les deux serveurs.

Le basculement actif-actif peut aussi être appelé basculement maître-maître.

Inconvénient(s) : basculement

Réplication

#### Maître-esclave et maître-maître

Ce sujet est abordé plus en détail dans la section Base de données :

Disponibilité en chiffres

La disponibilité est souvent quantifiée par le temps de fonctionnement (ou d’arrêt) en pourcentage du temps pendant lequel le service est disponible. La disponibilité est généralement mesurée en nombre de 9 -- un service avec une disponibilité de 99,99 % est décrit comme ayant quatre 9.

#### Disponibilité à 99,9 % - trois 9

| Durée | Temps d’arrêt acceptable | |---------------------|-------------------------| | Temps d’arrêt par an | 8h 45min 57s | | Temps d’arrêt par mois| 43m 49,7s | | Temps d’arrêt par semaine | 10m 4,8s | | Temps d’arrêt par jour| 1m 26,4s |

#### Disponibilité à 99,99 % - quatre 9

| Durée | Temps d’arrêt acceptable | |---------------------|-------------------------| | Temps d’arrêt par an | 52min 35,7s | | Temps d’arrêt par mois| 4m 23s | | Temps d’arrêt par semaine | 1m 5s | | Temps d’arrêt par jour| 8,6s |

#### Disponibilité en parallèle vs en séquence

Si un service est composé de plusieurs composants susceptibles de tomber en panne, la disponibilité globale du service dépend de si les composants sont en séquence ou en parallèle.

###### En séquence

La disponibilité globale diminue lorsque deux composants avec une disponibilité < 100 % sont en série :

Availability (Total) = Availability (Foo) * Availability (Bar)

Si Foo et Bar avaient chacun une disponibilité de 99,9 %, leur disponibilité totale en séquence serait de 99,8 %.

###### En parallèle

La disponibilité globale augmente lorsque deux composants avec une disponibilité < 100 % sont en parallèle :

Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))

Si à la fois Foo et Bar avaient chacun une disponibilité de 99,9 %, leur disponibilité totale en parallèle serait de 99,9999 %.

Système de noms de domaine


Source : Présentation sur la sécurité DNS

Un système de noms de domaine (DNS) traduit un nom de domaine tel que www.example.com en une adresse IP.

Le DNS est hiérarchique, avec quelques serveurs faisant autorité au niveau supérieur. Votre routeur ou FAI fournit des informations sur les serveurs DNS à contacter lors d'une recherche. Les serveurs DNS de niveau inférieur mettent en cache les correspondances, qui peuvent devenir obsolètes à cause des délais de propagation DNS. Les résultats DNS peuvent également être mis en cache par votre navigateur ou votre système d'exploitation pendant une certaine période, déterminée par le temps de vie (TTL).

Des services tels que CloudFlare et Route 53 fournissent des services DNS gérés. Certains services DNS peuvent router le trafic par différentes méthodes :

Inconvénient(s) : DNS

Source(s) et lectures complémentaires

Réseau de diffusion de contenu


Source : Pourquoi utiliser un CDN

Un réseau de diffusion de contenu (CDN) est un réseau mondialement distribué de serveurs proxy, servant le contenu depuis des emplacements plus proches de l'utilisateur. Généralement, des fichiers statiques tels que HTML/CSS/JS, photos, et vidéos sont servis depuis le CDN, bien que certains CDN comme CloudFront d'Amazon supportent du contenu dynamique. La résolution DNS du site indique aux clients quel serveur contacter.

Servir du contenu depuis des CDN peut significativement améliorer les performances de deux façons :

CDN push

Les CDN push reçoivent du nouveau contenu chaque fois qu’un changement se produit sur votre serveur. Vous assumez entièrement la responsabilité de fournir le contenu, en le téléchargeant directement vers le CDN et en réécrivant les URLs pour pointer vers le CDN. Vous pouvez configurer la durée d’expiration du contenu et quand il est mis à jour. Le contenu est téléchargé uniquement lorsqu’il est nouveau ou modifié, minimisant le trafic, mais maximisant le stockage.

Les sites avec peu de trafic ou des sites dont le contenu est rarement mis à jour fonctionnent bien avec les CDN push. Le contenu est placé sur le CDN une fois, au lieu d’être récupéré à intervalles réguliers.

CDN pull

Les CDN pull récupèrent le nouveau contenu depuis votre serveur lorsque le premier utilisateur demande ce contenu. Vous laissez le contenu sur votre serveur et réécrivez les URLs pour pointer vers le CDN. Cela entraîne une requête plus lente jusqu’à ce que le contenu soit mis en cache sur le CDN.

Un temps de vie (TTL) détermine la durée pendant laquelle le contenu est mis en cache. Les CDN pull minimisent l’espace de stockage sur le CDN, mais peuvent générer un trafic redondant si les fichiers expirent et sont récupérés avant d’avoir réellement changé.

Les sites à fort trafic fonctionnent bien avec les CDN pull, car le trafic est réparti plus uniformément avec seulement le contenu récemment demandé restant sur le CDN.

Inconvénient(s) : CDN

Source(s) et lectures complémentaires

Équilibreur de charge


Source : Modèles de conception de systèmes évolutifs

Les équilibreurs de charge distribuent les requêtes entrantes des clients vers des ressources informatiques telles que les serveurs d'application et les bases de données. Dans chaque cas, l'équilibreur de charge renvoie la réponse de la ressource informatique au client approprié. Les équilibreurs de charge sont efficaces pour :

Les équilibreurs de charge peuvent être mis en œuvre avec du matériel (coûteux) ou avec des logiciels tels que HAProxy.

Les avantages supplémentaires incluent :

Pour se protéger contre les défaillances, il est courant de configurer plusieurs équilibreurs de charge, soit en mode actif-passif soit en mode actif-actif.

Les équilibreurs de charge peuvent acheminer le trafic en fonction de divers critères, notamment :

Équilibrage de charge de couche 4

Les équilibreurs de charge de couche 4 examinent les informations à la couche transport pour décider comment distribuer les requêtes. Généralement, cela implique les adresses IP source et destination, ainsi que les ports dans l'en-tête, mais pas le contenu du paquet. Les équilibreurs de charge de couche 4 transmettent les paquets réseau vers et depuis le serveur en amont, en effectuant une traduction d'adresse réseau (NAT).

Équilibrage de charge de couche 7

Les équilibreurs de charge de couche 7 examinent la couche application pour décider comment répartir les requêtes. Cela peut impliquer le contenu des en-têtes, des messages et des cookies. Les équilibreurs de charge de couche 7 terminent le trafic réseau, lisent le message, prennent une décision de répartition de charge, puis ouvrent une connexion vers le serveur sélectionné. Par exemple, un équilibreur de charge de couche 7 peut diriger le trafic vidéo vers des serveurs hébergeant des vidéos tout en dirigeant le trafic plus sensible de facturation utilisateur vers des serveurs renforcés en sécurité.

Au prix d'une flexibilité moindre, l'équilibrage de charge de couche 4 nécessite moins de temps et de ressources informatiques que la couche 7, bien que l'impact sur les performances puisse être minimal sur du matériel standard moderne.

Mise à l'échelle horizontale

Les équilibreurs de charge peuvent également aider à la mise à l'échelle horizontale, améliorant les performances et la disponibilité. Monter en charge en utilisant des machines standard est plus rentable et offre une meilleure disponibilité que d'augmenter la capacité d'un seul serveur sur du matériel plus coûteux, appelé mise à l'échelle verticale. Il est aussi plus facile de recruter des talents pour travailler sur du matériel standard que pour des systèmes d'entreprise spécialisés.

#### Inconvénient(s) : mise à l'échelle horizontale

Inconvénient(s) : équilibreur de charge

Source(s) et lectures complémentaires

Proxy inverse (serveur web)


Source : Wikipedia

Un reverse proxy est un serveur web qui centralise les services internes et fournit des interfaces unifiées au public. Les requêtes des clients sont transmises à un serveur capable de les satisfaire avant que le reverse proxy ne renvoie la réponse du serveur au client.

Avantages supplémentaires :

Équilibreur de charge vs reverse proxy

Inconvénient(s) : reverse proxy

Sources et lectures complémentaires

Couche application


Source : Introduction à l’architecture des systèmes à grande échelle

Séparer la couche web de la couche application (également appelée couche plateforme) permet de faire évoluer et de configurer les deux couches indépendamment. Ajouter une nouvelle API se traduit par l’ajout de serveurs d’application sans forcément ajouter de serveurs web supplémentaires. Le principe de responsabilité unique prône des services petits et autonomes qui collaborent. De petites équipes avec de petits services peuvent planifier de manière plus agressive une croissance rapide.

Les workers dans la couche application aident aussi à permettre l’asynchronisme.

Microservices

En lien avec cette discussion, les microservices peuvent être décrits comme une suite de services petits, modulaires et déployables indépendamment. Chaque service exécute un processus unique et communique via un mécanisme léger bien défini pour servir un objectif métier. 1

Pinterest, par exemple, pourrait avoir les microservices suivants : profil utilisateur, abonné, flux, recherche, téléchargement de photo, etc.

Découverte de service

Des systèmes tels que Consul, Etcd et Zookeeper peuvent aider les services à se trouver en gardant la trace des noms, adresses et ports enregistrés. Les vérifications de santé aident à vérifier l’intégrité des services et sont souvent réalisées via un point d’accès HTTP. Consul et Etcd disposent tous deux d’un magasin clé-valeur intégré, utile pour stocker des valeurs de configuration et d’autres données partagées.

Inconvénient(s) : couche application

Source(s) et lectures complémentaires

Base de données


Source : Monter en charge jusqu’à vos premiers 10 millions d’utilisateurs

Système de gestion de base de données relationnelle (SGBDR)

Une base de données relationnelle comme SQL est une collection d'éléments de données organisés en tables.

ACID est un ensemble de propriétés des transactions dans une base de données relationnelle.

Il existe de nombreuses techniques pour faire évoluer une base de données relationnelle : réplication maître-esclave, réplication maître-maître, fédération, sharding, dénormalisation et optimisation SQL.

#### Réplication maître-esclave

Le maître gère les lectures et écritures, répliquant les écritures vers un ou plusieurs esclaves, qui ne servent que les lectures. Les esclaves peuvent aussi répliquer vers d'autres esclaves en forme d'arbre. Si le maître est hors ligne, le système peut continuer à fonctionner en mode lecture seule jusqu'à ce qu'un esclave soit promu maître ou qu'un nouveau maître soit provisionné.


Source : Scalability, availability, stability, patterns

##### Inconvénient(s) : réplication maître-esclave

#### Réplication maître-maître

Les deux maîtres gèrent lectures et écritures et se coordonnent sur les écritures. Si l'un des maîtres tombe en panne, le système peut continuer à fonctionner avec lectures et écritures.


Source : Scalability, availability, stability, patterns

##### Inconvénient(s) : réplication maître-maître

##### Inconvénient(s) : réplication

##### Source(s) et lecture complémentaire : réplication

#### Fédération


Source : Monter en charge jusqu’à vos premiers 10 millions d’utilisateurs

La fédération (ou partition fonctionnelle) divise les bases de données par fonction. Par exemple, au lieu d’une base de données monolithique unique, vous pourriez avoir trois bases de données : forums, utilisateurs et produits, ce qui réduit le trafic de lecture et d’écriture sur chaque base et donc le décalage de réplication. Des bases de données plus petites permettent de stocker davantage de données en mémoire, ce qui se traduit par plus de hits en cache grâce à une meilleure localité de cache. Sans maître central unique sérialisant les écritures, vous pouvez écrire en parallèle, augmentant ainsi le débit.

##### Inconvénient(s) : fédération

##### Source(s) et lecture complémentaire : fédération

#### Sharding


Source : Scalabilité, disponibilité, stabilité, modèles

Le sharding distribue les données à travers différentes bases de données de sorte que chaque base ne gère qu’un sous-ensemble des données. En prenant une base de données d’utilisateurs comme exemple, à mesure que le nombre d’utilisateurs augmente, plus de shards sont ajoutés au cluster.

Semblable aux avantages de la fédération, le sharding entraîne moins de trafic en lecture et écriture, moins de réplication, et plus de cache hits. La taille des index est également réduite, ce qui améliore généralement les performances avec des requêtes plus rapides. Si un shard tombe en panne, les autres shards restent opérationnels, bien que vous souhaitiez ajouter une forme de réplication pour éviter la perte de données. Comme pour la fédération, il n’y a pas de maître central unique qui sérialise les écritures, vous permettant d’écrire en parallèle avec un débit accru.

Les façons courantes de sharder une table d’utilisateurs sont soit par l’initiale du nom de famille de l’utilisateur, soit par la localisation géographique de l’utilisateur.

##### Inconvénient(s) : sharding

##### Source(s) et lectures complémentaires : sharding

#### Dénormalisation

La dénormalisation tente d’améliorer les performances en lecture au détriment de certaines performances en écriture. Des copies redondantes des données sont écrites dans plusieurs tables pour éviter des jointures coûteuses. Certains SGBDR comme PostgreSQL et Oracle supportent les vues matérialisées qui gèrent le travail de stockage des informations redondantes et maintiennent la cohérence des copies redondantes.

Une fois que les données sont distribuées avec des techniques telles que la fédération et le sharding, gérer des jointures entre centres de données augmente encore la complexité. La dénormalisation pourrait contourner le besoin de telles jointures complexes.

Dans la plupart des systèmes, les lectures peuvent dépasser largement les écritures, dans un rapport de 100:1 voire 1000:1. Une lecture résultant en une jointure complexe de base de données peut être très coûteuse, passant un temps significatif en opérations disque.

##### Inconvénient(s) : dénormalisation

###### Source(s) et lectures complémentaires : dénormalisation

#### Optimisation SQL

L'optimisation SQL est un sujet vaste et de nombreux livres ont été écrits à titre de référence.

Il est important de mesurer les performances et de profiler pour simuler et déceler les goulets d'étranglement.

La mesure et le profilage peuvent vous orienter vers les optimisations suivantes.

##### Resserrez le schéma

##### Utilisez de bons index

##### Évitez les jointures coûteuses

##### Partitionnez les tables

##### Optimiser le cache de requêtes

##### Source(s) et lectures complémentaires : optimisation SQL

NoSQL

NoSQL est un ensemble d’éléments de données représentés dans un magasin clé-valeur, magasin de documents, magasin à colonnes larges, ou une base de données graphe. Les données sont dénormalisées, et les jointures sont généralement effectuées dans le code de l’application. La plupart des magasins NoSQL ne disposent pas de véritables transactions ACID et privilégient la cohérence éventuelle.

BASE est souvent utilisé pour décrire les propriétés des bases de données NoSQL. En comparaison avec le théorème CAP, BASE choisit la disponibilité plutôt que la cohérence.

En plus de choisir entre SQL ou NoSQL, il est utile de comprendre quel type de base de données NoSQL correspond le mieux à votre ou vos cas d’usage. Nous examinerons les magasins clé-valeur, magasins de documents, magasins à colonnes larges et bases de données graphe dans la section suivante.

#### Magasin clé-valeur

Abstraction : table de hachage

Un magasin clé-valeur permet généralement des lectures et écritures en O(1) et est souvent basé sur la mémoire ou le SSD. Les magasins de données peuvent maintenir les clés en ordre lexicographique, permettant une récupération efficace des plages de clés. Les magasins clé-valeur peuvent permettre le stockage de métadonnées avec une valeur.

Les magasins clé-valeur offrent des performances élevées et sont souvent utilisés pour des modèles de données simples ou pour des données en évolution rapide, comme une couche de cache en mémoire. Comme ils n’offrent qu’un ensemble limité d’opérations, la complexité est transférée à la couche applicative si des opérations supplémentaires sont nécessaires.

Un magasin clé-valeur est la base de systèmes plus complexes tels qu’un magasin de documents, et dans certains cas, une base de données graphe.

##### Source(s) et lectures complémentaires : magasin clé-valeur

#### Magasin de documents

Abstraction : magasin clé-valeur avec des documents stockés en tant que valeurs

Un magasin de documents est centré autour des documents (XML, JSON, binaire, etc.), où un document contient toutes les informations pour un objet donné. Les magasins de documents fournissent des API ou un langage de requête pour interroger en fonction de la structure interne du document lui-même. Notez que de nombreux magasins clé-valeur incluent des fonctionnalités pour travailler avec les métadonnées d'une valeur, brouillant ainsi les frontières entre ces deux types de stockage.

Selon l'implémentation sous-jacente, les documents sont organisés par collections, tags, métadonnées ou répertoires. Bien que les documents puissent être organisés ou regroupés, ils peuvent contenir des champs complètement différents les uns des autres.

Certains magasins de documents comme MongoDB et CouchDB fournissent également un langage de type SQL pour effectuer des requêtes complexes. DynamoDB supporte à la fois les paires clé-valeur et les documents.

Les magasins de documents offrent une grande flexibilité et sont souvent utilisés pour travailler avec des données qui changent occasionnellement.

##### Source(s) et lectures complémentaires : magasin de documents

#### Magasin à colonnes larges


Source : SQL & NoSQL, une brève histoire

Abstraction : carte imbriquée ColumnFamily>

L'unité de base des données dans un magasin à colonnes larges est une colonne (paire nom/valeur). Une colonne peut être regroupée en familles de colonnes (analogue à une table SQL). Les super familles de colonnes regroupent davantage les familles de colonnes. Vous pouvez accéder à chaque colonne indépendamment via une clé de ligne, et les colonnes avec la même clé forment une ligne. Chaque valeur contient un horodatage pour la gestion des versions et la résolution des conflits.

Google a introduit Bigtable comme premier magasin à colonnes larges, qui a influencé l'open source HBase souvent utilisé dans l'écosystème Hadoop, ainsi que Cassandra de Facebook. Des magasins tels que BigTable, HBase et Cassandra maintiennent les clés en ordre lexicographique, permettant une récupération efficace de plages de clés sélectives.

Les magasins à colonnes larges offrent une haute disponibilité et une grande scalabilité. Ils sont souvent utilisés pour des ensembles de données très volumineux.

##### Source(s) et lectures complémentaires : magasin à colonnes larges

#### Base de données graphe


Source : Base de données graphe

Abstraction : graphe

Dans une base de données graphe, chaque nœud est un enregistrement et chaque arc est une relation entre deux nœuds. Les bases de données graphe sont optimisées pour représenter des relations complexes avec de nombreuses clés étrangères ou des relations plusieurs-à-plusieurs.

Les bases de données graphe offrent de hautes performances pour des modèles de données avec des relations complexes, comme un réseau social. Elles sont relativement récentes et ne sont pas encore largement utilisées ; il peut être plus difficile de trouver des outils de développement et des ressources. De nombreux graphes ne peuvent être accessibles qu’avec des API REST.

##### Source(s) et lectures complémentaires : graphe

#### Source(s) et lectures complémentaires : NoSQL

SQL ou NoSQL


Source : Transition des SGBDR vers NoSQL

Raisons pour SQL :

Raisons pour NoSQL :

Exemples de données adaptées à NoSQL :

##### Source(s) et lectures complémentaires : SQL ou NoSQL

Cache


Source : Modèles de conception de systèmes évolutifs

La mise en cache améliore les temps de chargement des pages et peut réduire la charge sur vos serveurs et bases de données. Dans ce modèle, le répartiteur cherchera d'abord si la requête a déjà été effectuée et essaiera de trouver le résultat précédent à retourner, afin d'économiser l'exécution réelle.

Les bases de données bénéficient souvent d'une répartition uniforme des lectures et écritures sur leurs partitions. Les éléments populaires peuvent fausser cette répartition, causant des goulots d'étranglement. Placer un cache devant une base de données peut aider à absorber les charges inégales et les pics de trafic.

Mise en cache côté client

Les caches peuvent être situés côté client (système d'exploitation ou navigateur), côté serveur, ou dans une couche de cache distincte.

Mise en cache CDN

Les CDN sont considérés comme un type de cache.

Mise en cache côté serveur web

Les reverse proxies et caches tels que Varnish peuvent servir directement du contenu statique et dynamique. Les serveurs web peuvent également mettre en cache les requêtes, retournant des réponses sans avoir à contacter les serveurs d’application.

Mise en cache côté base de données

Votre base de données inclut généralement un certain niveau de mise en cache en configuration par défaut, optimisé pour un cas d'utilisation générique. Ajuster ces paramètres pour des schémas d’utilisation spécifiques peut améliorer encore les performances.

Mise en cache côté application

Les caches en mémoire tels que Memcached et Redis sont des magasins clé-valeur entre votre application et votre stockage de données. Puisque les données sont conservées en RAM, c’est beaucoup plus rapide que les bases de données typiques où les données sont stockées sur disque. La RAM est plus limitée que le disque, donc les algorithmes de validation de cache tels que le moins récemment utilisé (LRU)) peuvent aider à invalider les entrées « froides » et garder les données « chaudes » en RAM.

Redis dispose des fonctionnalités supplémentaires suivantes :

Il existe plusieurs niveaux que vous pouvez mettre en cache, qui se répartissent en deux catégories générales : requêtes de base de données et objets :

En général, vous devriez essayer d’éviter la mise en cache basée sur des fichiers, car cela complique le clonage et l’auto-scaling.

Mise en cache au niveau des requêtes de base de données

Chaque fois que vous interrogez la base de données, hachez la requête en tant que clé et stockez le résultat dans le cache. Cette approche souffre de problèmes d'expiration :

Mise en cache au niveau de l'objet

Considérez vos données comme un objet, similaire à ce que vous faites avec votre code applicatif. Faites en sorte que votre application assemble le jeu de données depuis la base de données dans une instance de classe ou une structure(s) de données :

Suggestions de ce qu'il faut mettre en cache :

Quand mettre à jour le cache

Comme vous ne pouvez stocker qu'une quantité limitée de données dans le cache, vous devez déterminer quelle stratégie de mise à jour du cache convient le mieux à votre cas d'utilisation.

#### Cache-aside


Source : From cache to in-memory data grid

L'application est responsable de la lecture et de l'écriture dans le stockage. Le cache n'interagit pas directement avec le stockage. L'application fait ce qui suit :

def get_user(self, user_id):
    user = cache.get("user.{0}", user_id)
    if user is None:
        user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
        if user is not None:
            key = "user.{0}".format(user_id)
            cache.set(key, json.dumps(user))
    return user

Memcached est généralement utilisé de cette manière.

Les lectures ultérieures des données ajoutées au cache sont rapides. Cache-aside est également appelé chargement paresseux. Seules les données demandées sont mises en cache, ce qui évite de remplir le cache avec des données non demandées.

##### Inconvénient(s) : cache-aside

#### Écriture directe


Source : Scalabilité, disponibilité, stabilité, modèles

L'application utilise le cache comme magasin principal de données, lisant et écrivant les données dedans, tandis que le cache est responsable de la lecture et de l'écriture dans la base de données :

Code de l'application :

set_user(12345, {"foo":"bar"})

Code cache :

def set_user(user_id, values):
    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
    cache.set(user_id, user)

L'écriture directe (write-through) est une opération globale lente en raison de l'opération d'écriture, mais les lectures suivantes des données fraîchement écrites sont rapides. Les utilisateurs tolèrent généralement mieux la latence lors de la mise à jour des données que lors de la lecture des données. Les données dans le cache ne sont pas obsolètes.

##### Inconvénient(s) : write-through

#### Écriture différée (write-behind)


Source : Scalabilité, disponibilité, stabilité, modèles

Dans l'écriture différée, l'application fait ce qui suit :

##### Inconvénient(s) : write-behind

#### Rafraîchissement anticipé (refresh-ahead)


Source : Du cache à la grille de données en mémoire

Vous pouvez configurer le cache pour rafraîchir automatiquement toute entrée de cache récemment accédée avant son expiration.

Le rafraîchissement anticipé peut entraîner une réduction de la latence par rapport au read-through si le cache peut prédire avec précision quels éléments seront probablement nécessaires à l'avenir.

##### Inconvénient(s) : refresh-ahead

Inconvénient(s) : cache

Source(s) et lectures complémentaires

Asynchronisme


Source : Introduction à l’architecture des systèmes pour l’échelle

Les workflows asynchrones aident à réduire les temps de requête pour les opérations coûteuses qui seraient autrement effectuées en ligne. Ils peuvent également aider en réalisant à l’avance des travaux chronophages, tels que l’agrégation périodique des données.

Files de messages

Les files de messages reçoivent, retiennent et livrent les messages. Si une opération est trop lente à effectuer en ligne, vous pouvez utiliser une file de messages avec le workflow suivant :

L’utilisateur n’est pas bloqué et le travail est traité en arrière-plan. Pendant ce temps, le client peut éventuellement effectuer une petite quantité de traitement pour donner l’impression que la tâche est terminée. Par exemple, lors de la publication d’un tweet, le tweet peut être instantanément affiché dans votre timeline, mais il peut s’écouler un certain temps avant que votre tweet soit effectivement livré à tous vos abonnés.

Redis est utile en tant que simple broker de messages mais des messages peuvent être perdus.

RabbitMQ est populaire mais nécessite de s’adapter au protocole 'AMQP' et de gérer vos propres nœuds.

Amazon SQS est hébergé mais peut présenter une latence élevée et la possibilité que des messages soient livrés deux fois.

Files de tâches

Les files de tâches reçoivent des tâches et leurs données associées, les exécutent, puis livrent leurs résultats. Elles peuvent prendre en charge la planification et peuvent être utilisées pour exécuter des travaux intensifs en calcul en arrière-plan.

Celery prend en charge la planification et supporte principalement Python.

Rétropression (Back pressure)

Si les files d’attente commencent à croître de manière significative, la taille de la file peut dépasser la mémoire, entraînant des défauts de cache, des lectures sur disque et des performances encore plus lentes. La rétropression peut aider en limitant la taille de la file, maintenant ainsi un débit élevé et de bons temps de réponse pour les tâches déjà en attente. Une fois la file remplie, les clients reçoivent un statut serveur occupé ou HTTP 503 pour réessayer plus tard. Les clients peuvent réessayer la requête ultérieurement, peut-être avec un exponential backoff.

Inconvénient(s) : asynchronisme

Source(s) et lectures complémentaires

Communication


Source : modèle OSI en 7 couches

Protocole de transfert hypertexte (HTTP)

HTTP est une méthode pour encoder et transporter des données entre un client et un serveur. C’est un protocole requête/réponse : les clients émettent des requêtes et les serveurs renvoient des réponses avec le contenu pertinent et des informations sur le statut de la requête. HTTP est autonome, permettant aux requêtes et réponses de transiter par de nombreux routeurs et serveurs intermédiaires qui effectuent équilibrage de charge, mise en cache, chiffrement et compression.

Une requête HTTP basique se compose d’un verbe (méthode) et d’une ressource (point de terminaison). Voici les verbes HTTP courants :

| Verbe | Description | Idempotent* | Sûr | Mise en cache |

| GET | Lit une ressource | Oui | Oui | Oui | | POST | Crée une ressource ou déclenche un processus qui traite les données | Non | Non | Oui si la réponse contient des informations de fraîcheur | | PUT | Crée ou remplace une ressource | Oui | Non | Non | | PATCH | Met à jour partiellement une ressource | Non | Non | Oui si la réponse contient des informations de fraîcheur | | DELETE | Supprime une ressource | Oui | Non | Non |

*Peut être appelé plusieurs fois sans résultats différents.

HTTP est un protocole de couche application reposant sur des protocoles de niveau inférieur tels que TCP et UDP.

#### Source(s) et lectures complémentaires : HTTP

Protocole de contrôle de transmission (TCP)


Source : Comment créer un jeu multijoueur

TCP est un protocole orienté connexion sur un réseau IP. La connexion est établie et terminée via une poignée de main (handshake). Tous les paquets envoyés sont garantis d’atteindre la destination dans l’ordre initial et sans corruption grâce à :

Si l’émetteur ne reçoit pas une réponse correcte, il renverra les paquets. En cas de multiples délais d’attente, la connexion est interrompue. TCP implémente également le contrôle de flux) et le contrôle de congestion. Ces garanties causent des délais et entraînent généralement une transmission moins efficace que UDP.

Pour garantir un débit élevé, les serveurs web peuvent garder un grand nombre de connexions TCP ouvertes, ce qui entraîne une utilisation élevée de la mémoire. Il peut être coûteux d’avoir un grand nombre de connexions ouvertes entre les threads du serveur web et par exemple, un serveur memcached. Le pooling de connexions peut aider en plus du passage à UDP lorsque cela est applicable.

TCP est utile pour les applications nécessitant une haute fiabilité mais moins critiques en temps. Quelques exemples incluent les serveurs web, les bases de données, SMTP, FTP et SSH.

Utilisez TCP plutôt que UDP lorsque :

Protocole datagramme utilisateur (UDP)


Source : Comment créer un jeu multijoueur

UDP est sans connexion. Les datagrammes (analogues aux paquets) sont garantis uniquement au niveau du datagramme. Les datagrammes peuvent arriver à destination dans le désordre ou pas du tout. UDP ne supporte pas le contrôle de congestion. Sans les garanties que TCP offre, UDP est généralement plus efficace.

UDP peut diffuser, envoyant des datagrammes à tous les appareils sur le sous-réseau. Ceci est utile avec DHCP car le client n'a pas encore reçu d'adresse IP, empêchant ainsi TCP de diffuser sans adresse IP.

UDP est moins fiable mais fonctionne bien dans des cas d'utilisation en temps réel tels que VoIP, chat vidéo, streaming et jeux multijoueurs en temps réel.

Utilisez UDP plutôt que TCP quand :

#### Sources et lectures complémentaires : TCP et UDP

Appel de procédure distante (RPC)


Source : Réussir l'entretien de conception système

Dans un RPC, un client déclenche l'exécution d'une procédure dans un espace d'adressage différent, généralement un serveur distant. La procédure est codée comme s'il s'agissait d'un appel de procédure local, masquant les détails de la communication avec le serveur au programme client. Les appels distants sont généralement plus lents et moins fiables que les appels locaux, il est donc utile de distinguer les appels RPC des appels locaux. Les frameworks RPC populaires incluent Protobuf, Thrift, et Avro.

RPC est un protocole requête-réponse :

Exemples d’appels RPC :

GET /someoperation?data=anId
POST /anotheroperation
{
  "data":"anId";
  "anotherdata": "another value"
}

RPC se concentre sur l'exposition des comportements. Les RPC sont souvent utilisés pour des raisons de performance dans les communications internes, car vous pouvez créer manuellement des appels natifs pour mieux adapter vos cas d'utilisation.

Choisissez une bibliothèque native (également appelée SDK) lorsque :

Les API HTTP suivant REST ont tendance à être utilisées plus fréquemment pour les API publiques.

#### Inconvénient(s) : RPC

Représentation de transfert d'état (REST)

REST est un style architectural imposant un modèle client/serveur où le client agit sur un ensemble de ressources gérées par le serveur. Le serveur fournit une représentation des ressources et des actions qui peuvent soit manipuler, soit obtenir une nouvelle représentation des ressources. Toute communication doit être sans état et mise en cache.

Il y a quatre qualités d'une interface RESTful :

Exemples d'appels REST :

GET /someresources/anId
PUT /someresources/anId
{"anotherdata": "another value"}
REST se concentre sur l'exposition des données. Il minimise le couplage entre client/serveur et est souvent utilisé pour les API HTTP publiques. REST utilise une méthode plus générique et uniforme d'exposition des ressources via des URI, représentation via les en-têtes, et des actions via des verbes tels que GET, POST, PUT, DELETE et PATCH. Étant sans état, REST est idéal pour la montée en charge horizontale et le partitionnement.

#### Inconvénient(s) : REST

Comparaison des appels RPC et REST

| Opération | RPC | REST | |---|---|---| | Inscription | POST /signup | POST /persons | | Démission | POST /resign
{
"personid": "1234"
} | DELETE /persons/1234 | | Lire une personne | GET /readPerson?personid=1234 | GET /persons/1234 | | Lire la liste d'articles d'une personne | GET /readUsersItemsList?personid=1234 | GET /persons/1234/items | | Ajouter un article à la liste d'articles d'une personne | POST /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | POST /persons/1234/items
{
"itemid": "456"
} | | Mettre à jour un article | POST /modifyItem
{
"itemid": "456";
"key": "value"
} | PUT /items/456
{
"key": "value"
} | | Supprimer un article | POST /removeItem
{
"itemid": "456"
} | DELETE /items/456 |

Source : Savez-vous vraiment pourquoi vous préférez REST à RPC

#### Source(s) et lectures complémentaires : REST et RPC

Sécurité

Cette section pourrait être mise à jour. Envisagez de contribuer !

La sécurité est un sujet vaste. À moins que vous n'ayez une expérience considérable, un background en sécurité, ou que vous postuliez à un poste nécessitant des connaissances en sécurité, vous n'aurez probablement pas besoin de connaître plus que les bases :

Source(s) et lectures complémentaires

Annexe

Il vous sera parfois demandé de faire des estimations rapides. Par exemple, vous pourriez devoir déterminer combien de temps il faudra pour générer 100 miniatures d’images à partir du disque ou combien de mémoire une structure de données occupera. Le tableau des puissances de deux et les chiffres de latence que tout programmeur devrait connaître sont des références utiles.

Tableau des puissances de deux

Power           Exact Value         Approx Value        Bytes
---------------------------------------------------------------
7                             128
8                             256
10                           1024   1 thousand           1 KB
16                         65,536                       64 KB
20                      1,048,576   1 million            1 MB
30                  1,073,741,824   1 billion            1 GB
32                  4,294,967,296                        4 GB
40              1,099,511,627,776   1 trillion           1 TB

#### Source(s) et lectures complémentaires

Nombres de latence que tout programmeur devrait connaître

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy            10,000   ns       10 us
Send 1 KB bytes over 1 Gbps network     10,000   ns       10 us
Read 4 KB randomly from SSD*           150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
HDD seek                            10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from 1 Gbps  10,000,000   ns   10,000 us   10 ms  40x memory, 10X SSD
Read 1 MB sequentially from HDD     30,000,000   ns   30,000 us   30 ms 120x memory, 30X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms
Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

Métriques pratiques basées sur les chiffres ci-dessus :

#### Visualisation des chiffres de latence

#### Source(s) et lectures complémentaires

Questions supplémentaires d’entretien de conception système

Questions courantes d’entretien de conception système, avec des liens vers des ressources pour résoudre chacune.

| Question | Référence(s) | |---|---| | Concevoir un service de synchronisation de fichiers comme Dropbox | youtube.com | | Concevoir un moteur de recherche comme Google | queue.acm.org
stackexchange.com
ardendertat.com
stanford.edu | | Concevoir un robot d’indexation web évolutif comme Google | quora.com | | Concevoir Google Docs | code.google.com
neil.fraser.name | | Concevoir un magasin clé-valeur comme Redis | slideshare.net | | Concevoir un système de cache comme Memcached | slideshare.net | | Concevoir un système de recommandation comme celui d’Amazon | hulu.com
ijcai13.org | | Concevoir un système tinyurl comme Bitly | n00tc0d3r.blogspot.com | | Concevoir une application de chat comme WhatsApp | highscalability.com | Concevoir un système de partage de photos comme Instagram | highscalability.com
highscalability.com | | Concevoir la fonction fil d’actualité de Facebook | quora.com
quora.com
slideshare.net | | Concevoir la fonction timeline de Facebook | facebook.com
highscalability.com | | Concevoir la fonction chat de Facebook | erlang-factory.com
facebook.com | | Concevoir une fonction de recherche de graphe comme celle de Facebook | facebook.com
facebook.com
facebook.com | | Concevoir un réseau de diffusion de contenu comme CloudFlare | figshare.com | | Concevoir un système de sujets tendance comme celui de Twitter | michael-noll.com
snikolov.wordpress.com | | Concevoir un système de génération d’identifiants aléatoires | blog.twitter.com
github.com | | Retourner les k requêtes les plus fréquentes durant un intervalle de temps | cs.ucsb.edu
wpi.edu | | Concevoir un système qui sert des données depuis plusieurs centres de données | highscalability.com | | Concevoir un jeu de cartes multijoueur en ligne | indieflashblog.com
buildnewgames.com | | Concevoir un système de collecte des déchets (garbage collection) | stuffwithstuff.com
washington.edu | | Concevoir un limiteur de débit d’API | https://stripe.com/blog/ | | Concevoir une Bourse (comme NASDAQ ou Binance) | Jane Street
Golang Implementation
Go Implementation | | Ajouter une question de conception système | Contribuer |

Architectures du monde réel

Articles sur la manière dont les systèmes réels sont conçus.


Source : Échelles des timelines Twitter

Ne vous concentrez pas sur les détails techniques dans les articles suivants, mais plutôt :

|Type | Système | Référence(s) | |---|---|---| | Traitement de données | MapReduce - Traitement distribué de données par Google | research.google.com | | Traitement de données | Spark - Traitement distribué de données par Databricks | slideshare.net | | Traitement de données | Storm - Traitement distribué de données par Twitter | slideshare.net | | | | | | Stockage de données | Bigtable - Base de données orientée colonnes distribuée de Google | harvard.edu | | Stockage de données | HBase - Implémentation open source de Bigtable | slideshare.net | | Stockage de données | Cassandra - Base de données orientée colonnes distribuée de Facebook | slideshare.net | | Stockage de données | DynamoDB - Base de données orientée documents d’Amazon | harvard.edu | | Stockage de données | MongoDB - Base de données orientée documents | slideshare.net | | Stockage de données | Spanner - Base de données distribuée globalement par Google | research.google.com | | Stockage de données | Memcached - Système de cache mémoire distribué | slideshare.net | | Stockage de données | Redis - Système de cache mémoire distribué avec persistance et types de valeurs | slideshare.net | | | | | | Système de fichiers | Google File System (GFS) - Système de fichiers distribué | research.google.com | | Système de fichiers | Hadoop File System (HDFS) - Implémentation open source de GFS | apache.org | | | | | | Divers | Chubby - Service de verrouillage pour systèmes distribués faiblement couplés de Google | research.google.com | | Divers | Dapper - Infrastructure de traçage des systèmes distribués | research.google.com | | Divers | Kafka - File de messages pub/sub de LinkedIn | slideshare.net | | Divers | Zookeeper - Infrastructure centralisée et services permettant la synchronisation | slideshare.net | | | Ajouter une architecture | Contribuer |

Architectures d’entreprises

| Entreprise | Référence(s) | |---|---| | Amazon | Architecture Amazon | | Cinchcast | Production de 1 500 heures d’audio chaque jour | | DataSift | Datamining en temps réel à 120 000 tweets par seconde | | Dropbox | Comment nous avons fait évoluer Dropbox | | ESPN | Fonctionnement à 100 000 duh nuh nuhs par seconde | | Google | Architecture Google | | Instagram | 14 millions d’utilisateurs, des téraoctets de photos
Ce qui alimente Instagram | | Justin.tv | Architecture de diffusion vidéo en direct de Justin.Tv | | Facebook | Mise à l’échelle de memcached chez Facebook
TAO : magasin de données distribué de Facebook pour le graphe social
Stockage des photos chez Facebook
Comment Facebook diffuse en direct à 800 000 spectateurs simultanés | | Flickr | Architecture Flickr | | Mailbox | De 0 à un million d’utilisateurs en 6 semaines | | Netflix | Vue à 360 degrés de toute la pile Netflix
Netflix : que se passe-t-il quand vous appuyez sur play ? | | Pinterest | De 0 à des dizaines de milliards de pages vues par mois
18 millions de visiteurs, croissance de 10x, 12 employés | | Playfish | 50 millions d’utilisateurs mensuels et en croissance | | PlentyOfFish | Architecture PlentyOfFish | | Salesforce | Comment ils gèrent 1,3 milliard de transactions par jour | | Stack Overflow | Architecture Stack Overflow | | TripAdvisor | 40 millions de visiteurs, 200 millions de pages dynamiques vues, 30 To de données | | Tumblr | 15 milliards de pages vues par mois | | Twitter | Rendre Twitter 10 000 % plus rapide
Stocker 250 millions de tweets par jour avec MySQL
150 millions d’utilisateurs actifs, 300 000 QPS, un firehose de 22 Mo/s
Timelines à grande échelle
Données grandes et petites chez Twitter
Opérations chez Twitter : montée en charge au-delà de 100 millions d’utilisateurs
Comment Twitter gère 3 000 images par seconde | | Uber | Comment Uber met à l’échelle sa plateforme de marché en temps réel
Leçons apprises de la montée en charge d’Uber à 2 000 ingénieurs, 1 000 services et 8 000 dépôts Git | | WhatsApp | L’architecture WhatsApp que Facebook a achetée pour 19 milliards de dollars | | YouTube | Scalabilité YouTube
Architecture YouTube |

Blogs d'ingénierie des entreprises

Architectures pour les entreprises avec lesquelles vous passez des entretiens.
>
Les questions que vous rencontrez peuvent provenir du même domaine.

#### Source(s) et lectures complémentaires

Vous souhaitez ajouter un blog ? Pour éviter de dupliquer le travail, envisagez d'ajouter le blog de votre entreprise dans le dépôt suivant :

En cours de développement

Intéressé à ajouter une section ou à aider à en compléter une en cours ? Contribuez !

Crédits

Les crédits et sources sont fournis tout au long de ce dépôt.

Remerciements particuliers à :

Infos de contact

N’hésitez pas à me contacter pour discuter de tout problème, question ou commentaire.

Mes coordonnées se trouvent sur ma page GitHub.

Licence

Je vous fournis le code et les ressources de ce dépôt sous une licence open source. Puisqu’il s’agit de mon dépôt personnel, la licence que vous recevez pour mon code et mes ressources vient de moi et non de mon employeur (Facebook).

Copyright 2017 Donne Martin

Licence Creative Commons Attribution 4.0 International (CC BY 4.0)

http://creativecommons.org/licenses/by/4.0/

--- Tranlated By Open Ai Tx | Last indexed: 2025-08-09 ---

Original README: View on GitHub

Translated by OpenAiTx | Last updated: 2025-09-16