System design

Chaque exercice est noté sur ce que ton architecture accomplit, pas sur sa ressemblance avec la nôtre.

Commence ici

Ta première application web

Une boulangerie de quartier veut prendre des commandes en ligne. Mets son application en ligne : les clients doivent pouvoir consulter le menu et commander toute la journée.

  • Débutant
  • Construire
  • Environ 10 min
Commencer l'exercice
90%

Débutant gratuit

Suivre une requête du navigateur jusqu'à la base et garder une application simple en ligne sous un vrai trafic.

0 sur 9 réussis

  1. Ta première application web Une boulangerie de quartier veut prendre des commandes en ligne. Mets son application en ligne : les clients doivent pouvoir consulter le menu et commander toute la journée. Modèle client-serveurBases relationnellesOrdres de grandeur de latence Construire Environ 10 min
  2. Dimensionne la machine virtuelle L'équipe a pris une grosse machine à 32 vCPU, pourtant le site rame et la facture explose. Trouve ce qui cloche dans la configuration et corrige-la. Scaling verticalFiles d'attente et taux d'occupationOptimisation des coûts cloud Réparer Environ 10 min
  3. Survis à la panne d'un serveur À 10 h, un de tes serveurs applicatifs va planter. Personne ne surveille les tableaux de bord. Garde quand même le site disponible. Point de défaillance uniqueScaling horizontalRépartition de charge Construire Environ 15 min
  4. Servir des images en Europe Une place de marché de photos montréalaise cartonne en France. Les pages y semblent lentes car chaque image traverse l'Atlantique. Fais charger les images rapidement pour les visiteurs européens. Réseau de diffusion de contenu (CDN)Stockage objetOrdres de grandeur de latence Construire Environ 15 min
  5. Soulage la base de données Un site d'actualités est bien plus lu qu'écrit. La base est le goulot d'étranglement et le budget ne permet pas d'en prendre une plus grosse. Mise en cacheCache-asideDurée de vie (TTL) Construire Environ 15 min
  6. Le jour du lancement Un studio de jeux lance son titre à midi et attend quatre fois le trafic habituel pendant une heure. Tiens le choc sans payer un datacenter. Planification de capacitéFiles d'attente et taux d'occupationScaling horizontal Construire Environ 15 min
  7. Le runtime paie la facture Une API de réservation tourne sur six serveurs Python déjà à bout, et la direction financière veut réduire la facture. L'équipe peut redéployer la même API en Go, Java ou Python. Rends-la rapide et moins chère. Scaling horizontalScaling verticalOptimisation des coûts cloud Réparer Environ 15 min
  8. Deux serveurs, ce n'est pas de la redondance La boutique tourne déjà sur quatre serveurs derrière un load balancer, pourtant à 13 h une panne de courant va mettre la zone A hors ligne pendant une heure. Continue à vendre. Point de défaillance uniqueBasculement (failover)La disponibilité et les « nines » Réparer Environ 15 min
  9. La base va planter à 11 h Un site de billetterie garde tout sur un seul serveur de base de données. À 11 h, son disque va lâcher. Reste en ligne et ne perds aucune vente de billet. Basculement (failover)RPO et RTORéplication synchrone et asynchrone Réparer Environ 15 min
99%

Intermédiaire

Concevoir une application web qui absorbe la charge, survit à la panne d'un serveur et respecte un budget.

Débloquer avec la formule Intermédiaire
  1. Raccourcisseur d'URL Conçois un service qui crée des liens courts et redirige 12 000 visiteurs par seconde, avec un budget mensuel de 2 500 dollars. Mise en cacheAuto-scalingEstimation sur un coin de table Construire Aperçu
  2. Ne payer que les heures de bureau Une plateforme RH est chargée de 9 h à 18 h et presque vide la nuit, mais fait tourner dix serveurs jour et nuit. Réduis la facture sans pénaliser le rush du matin. Auto-scalingÉlasticitéOptimisation des coûts cloud Faire évoluer Aperçu
  3. Un paiement qui n'attend jamais Pendant les ventes flash, les commandes arrivent en rafales et l'étape de paiement est lente. Accepte chaque commande instantanément, traite-les de façon fiable et ne débite jamais deux fois un client. Files de messagesTraitement asynchroneIdempotence Construire Aperçu
  4. Trop de connexions Une marketplace est passée à 100 serveurs d'API et maintenant la base refuse des connexions et les lectures sont lentes. Répare la couche de données sans que les utilisateurs perdent la vue sur leurs propres modifications. Pool de connexionsRéplicas en lectureLire ses propres écritures Réparer Aperçu
  5. L'authentification est le goulot Une API partenaires vérifie chaque requête en appelant le service d'identité. Les partenaires envoient maintenant 6 000 requêtes par seconde et le service d'identité suffoque. Garde chaque requête authentifiée. API GatewayJSON Web Tokens (JWT)Authentification Réparer Aperçu
  6. Chercher sans faire fondre la base Une marketplace d'occasion a ajouté une barre de recherche. Un tiers des lectures sont désormais des recherches textuelles en LIKE, et la base est à genoux. Index inverséRecherche plein texteCQRS Faire évoluer Aperçu
  7. Un prestataire de paiement lent Le paiement appelle un prestataire qui répond en 380 ms, échoue de temps en temps et te limite. Les clients doivent recevoir une confirmation immédiate et personne ne doit jamais être débité deux fois. Dépendances tiercesTraitement asynchroneIdempotence Construire Aperçu
99.9%

Avancé

Construire des systèmes distribués et choisir en conscience entre cohérence, latence et disponibilité.

Débloquer avec la formule Avancé
  1. Un panier qui n'oublie rien Des clients ajoutent un article au panier et le voient parfois disparaître à la page suivante. Le panier vit dans un cluster Cassandra. À 11 h, un nœud va tomber. Rends le panier cohérent et garde-le disponible. QuorumsThéorème CAPPACELC Réparer Aperçu
  2. Sharde le chemin d'écriture Une application de VTC enregistre la position de chaque chauffeur. Les écritures dépassent la plus grosse instance de base disponible. Fais-les passer à l'échelle horizontalement. ShardingStratégies de partitionnementHachage cohérent Faire évoluer Aperçu
  3. Arrête la cascade À 10 h, le service de recommandations va tomber pendant une heure. La dernière fois, toute la boutique est tombée avec lui. Garde la boutique en vente pendant l'indisponibilité des recommandations. Circuit breakerPannes en cascadeTimeouts Réparer Aperçu
  4. Arrête les scrapers Des bots aspirent toutes les pages produits d'un commerçant, et à 14 h ils vont se multiplier par cinq. Garde les vrais clients rapides tout en bloquant les bots. Limitation de débitDéfense en profondeurDélestage Construire Aperçu
  5. Les partitions plafonnent ton parallélisme Un pipeline de clickstream écrit 20 000 événements par seconde dans un journal. L'équipe a ajouté des consommateurs, pourtant le retard grossit et les tableaux de bord ont des heures de retard. Fais suivre le pipeline. Groupes de consommateursStratégies de partitionnementStreaming d'événements Réparer Aperçu
  6. Le problème de la célébrité Un réseau social stocke les profils dans une base clé-valeur qui passe à l'échelle presque sans limite. Puis une célébrité s'inscrit : un quart de toutes les lectures visent désormais une seule clé, et les requêtes commencent à échouer. Clés et partitions chaudesStratégies de partitionnementMise en cache Réparer Aperçu
  7. Un replica set qui survit à une zone Les commandes vivent dans une base documentaire à trois membres. À 9 h le primaire va planter, et à 13 h la zone A va s'éteindre pendant une heure. Continue à prendre des commandes sans jamais en perdre une confirmée. Élection de leaderQuorumsWrite concern et accusé de réception Réparer Aperçu
  8. Un cache froid en plein pic Un site d'actualité sportive sert 20 000 lectures par seconde depuis Redis, et la base ne voit que les rares misses. À 15:00, en plein pic de l'après-midi, une release change le format des clés du cache : toutes les clés ratent d'un coup. Garde le site debout pendant que le cache se réchauffe. Ruée sur le cacheEffet troupeauRéplicas en lecture Réparer Aperçu
  9. Absorber le déluge en bordure Un groupe d'extorsion a promis d'inonder un site de billetterie parisien à 20:00, au moment précis où les places d'un concert sont mises en vente : 1,2 million de requêtes par seconde pendant une heure, depuis un botnet de centaines de milliers de machines. Permets aux vrais fans de continuer à acheter. Protection contre les DDoSAnycastDéfense en profondeur Réparer Aperçu
  10. Des démarrages à froid dans la traîne Une banque a migré son API de comptes vers des fonctions serverless écrites en Java. La latence moyenne est excellente, pourtant l'équipe mobile rate son objectif de 300 ms au p99 d'un facteur trois. Fais baisser la traîne sans exploser le budget de 3 000 dollars par mois. Démarrages à froidLatence de queueLoi de Little Réparer Aperçu
99.99%

Expert

Exploiter des plateformes multi-régions avec consensus, streaming d'événements et reprise après sinistre.

Débloquer avec la formule Expert
  1. L'exercice de reprise après sinistre Une pharmacie en ligne tourne à Montréal, avec une région de secours en Virginie et un basculement DNS. Le régulateur veut la preuve que ça marche : à 15:00, l'exercice éteint Montréal pendant trois heures. Les ordonnances continuent d'arriver, et aucune ne doit être perdue. Stratégies de reprise après sinistreRPO et RTOBasculement (failover) Réparer Aperçu
  2. Basculer en secondes, pas en minutes Une néobanque parisienne promet 99,95 % de disponibilité. Elle tourne en actif-passif entre Paris et Francfort avec un basculement DNS, et son grand livre est déjà répliqué sur trois régions. À 15:00, Paris tombe pour deux heures. Tiens la promesse. Actif-actif et actif-passifAnycastHealth checks Réparer Aperçu
  3. Un grand livre qui survit à sa région Une société de paiements nord-américaine sert déjà son trafic depuis la Virginie et Montréal derrière un load balancer global. Son grand livre, un cluster SQL distribué, tourne encore entièrement en Virginie. À 14:00, la Virginie s'éteint pour trois heures, et à 15:30 un nœud du grand livre plante alors que la région est toujours hors ligne. Garde chaque paiement en mouvement. ConsensusRaft et PaxosQuorums Réparer Aperçu
  4. Aucune région ne dépend d'une autre Une marketplace d'électronique tourne en actif-actif à Paris et Francfort, avec une base de commandes répliquée sur trois régions. Pourtant, chaque requête, dans les deux régions, appelle un service de prix et de TVA qui ne tourne qu'à Paris. À 17:00, Paris tombe pour deux heures. Garde la marketplace en vente. Stabilité statiqueArchitecture multi-régionsPannes en cascade Réparer Aperçu
  5. Une télémétrie qui survit à une région Une plateforme de compteurs intelligents ingère 50 000 relevés par seconde depuis des foyers nord-américains via deux pipelines régionaux identiques, en Virginie et à Montréal, derrière un load balancer global. Chaque pipeline a été dimensionné pour la moitié des compteurs. À 14:00, la Virginie disparaît pour deux heures et tous les compteurs se reconnectent à Montréal. Ne perds et ne compte en double aucun relevé. Streaming d'événementsStratégies de partitionnementGroupes de consommateurs Réparer Aperçu
  6. Exactement-une-fois à 8 000 virements par seconde Une appli de paiement traite les virements entre particuliers de façon asynchrone. L'équipe a choisi une file FIFO pour sa garantie exactement-une-fois, mais à 8 000 virements par seconde l'API se fait maintenant limiter. Applique chaque virement exactement une fois, suis le rythme et reste dans un budget mensuel de 22 000 dollars. Traitement exactement-une-foisIdempotenceGaranties de livraison Réparer Aperçu
  7. Lire en local, écrire dans la région d'origine Un commerçant de Virginie s'ouvre à Singapour. La loi impose que ses commandes soient stockées dans sa base de Virginie : aujourd'hui, chaque requête de Singapour traverse le Pacifique, environ 220 ms aller-retour. Donne à Singapour l'impression d'une boutique locale : pages rapides, confirmation de commande immédiate et chaque commande en Virginie en moins d'une demi-minute. Région d'origine et transfert des écrituresOrdres de grandeur de latenceMise en cache Faire évoluer Aperçu
  8. Projet final : des paiements multi-régions Conçois de zéro l'API de paiement d'un portefeuille européen : 8 000 lectures de solde et 1 000 paiements par seconde au pic, 99,95 % de disponibilité, aucun paiement perdu, et une notification push pour chaque paiement. À 16:00, Paris tombe pour deux heures, et à 17:00 un nœud de base de données plante alors que Paris est toujours hors ligne. Budget : 25 000 dollars par mois. Architecture multi-régionsActif-actif et actif-passifConsensus Construire Aperçu
99.999%

Architecte

Défendre une architecture face aux vraies contraintes d'entreprise : coûts, migration, conformité et équipes.

Débloquer avec la formule Architecte
  1. Cinq fois moins cher, aussi fiable Une plateforme de recettes berlinoise sert 12 000 requêtes par seconde à son pic de l'après-midi et paie environ 65 000 dollars par mois pour ça. Les investisseurs veulent une facture sous les 12 000 dollars sans perdre le SLO : 99,9 % de disponibilité, un p99 sous 200 ms, et aucune écriture perdue quand le primaire de la base tombe à 10:00 ou qu'un serveur web plante à 13:00. Optimisation des coûts cloudAuto-scalingMise en cache Réparer Aperçu
  2. Contenir le rayon d'impact Une plateforme de facturation B2B sert 4 000 entreprises depuis une seule pile partagée. Le trimestre dernier, une migration de schéma a verrouillé la base partagée pendant une demi-heure et tous les clients sont tombés en même temps. Les nouveaux contrats entreprise plafonnent ce qu'un incident peut coûter. Aujourd'hui, une migration va de nouveau verrouiller la base la plus chargée à 10:00, pendant 30 minutes. Contiens-la, sans dépenser plus qu'aujourd'hui. Architecture cellulaireRayon d'impactMulti-location (multi-tenancy) Faire évoluer Aperçu
  3. Planifier le lancement à 10x Un studio de jeu ouvre sa nouvelle saison à 19:00 : pendant deux heures, son application compagnon recevra dix fois son trafic habituel, de 5 500 à 55 000 requêtes par seconde, puis retombera. Le marketing l'a déjà annoncé. Reste debout et rapide pendant le lancement, et garde la facture mensuelle sous les 13 000 dollars. Planification de capacitéÉlasticitéAuto-scaling Faire évoluer Aperçu
  4. Tout n'a pas besoin de consensus Un jeu multijoueur garde les comptes et les achats des joueurs dans un cluster SQL distribué réparti sur trois régions, et c'est le bon choix : l'argent ne doit jamais diverger. Mais les serveurs de jeu écrivent aussi chaque événement de partie dans le même cluster, 30 000 écritures par seconde qui ne servent qu'aux replays et aux statistiques. La facture a triplé et les achats sont devenus lents. Ramène la plateforme sous les 15 000 dollars par mois avec un p99 sous 250 ms. Persistance polyglotteConsensusPACELC Réparer Aperçu
  5. Démêler le monolithe distribué Trois équipes possèdent les services catalogue, panier et avis d'une boutique de mode, mais les trois services partagent encore une seule base. À 10:00, l'équipe avis lance une migration qui verrouille cette base pendant une heure, et aujourd'hui cela fait tomber toute la boutique. La nouvelle règle : le changement d'une équipe ne doit jamais faire tomber la fonctionnalité d'une autre. Les avis peuvent disparaître des pages pendant leur incident ; la navigation et le paiement, non. Monolithe et microservicesLoi de ConwayCloisons (bulkheads) Réparer Aperçu
  6. Étrangler le monolithe, sans casse Le moteur de devis d'un assureur est un monolithe .NET sur huit grands serveurs Windows, et ses licences dévorent le budget. Le nouveau service de devis en Go est déployé mais n'a jamais reçu de trafic de production. La finance veut une infrastructure sous les 6 000 dollars par mois dès aujourd'hui. L'équipe chaos a prévu un exercice : à 14:00, le nouveau service plante pendant 30 minutes. Migration par étranglement (strangler fig)Déploiements canary et blue-greenHealth checks Faire évoluer Aperçu