Aller au contenu
English
Compte : non connecté, synchronisation possible Mon apprentissage
Selectionner le thème
English

Capstone : lire une architecture complète, de la requête à la reprise

Par mis à jour le

Améliorer cette page

Le capstone vérifie que vous savez lire seul une architecture complète que vous n'avez jamais vue : reconnaître chaque famille, suivre les flux, classer l'état, repérer les points faibles, prédire les pannes et juger l'exploitation. C'est la synthèse des six modules, sur un système plus riche que les checkpoints : une plateforme de livraison de repas. Il ne demande aucune commande ni aucun produit par cœur : chaque réponse se déduit du diagramme et de la grille de lecture de la formation, et une erreur renvoie à la leçon qui traite le point manqué.

  • Reconnaître la famille de chaque brique d'une architecture inconnue
  • Classer l'état et dire ce qu'il faut sauvegarder
  • Suivre les flux synchrones et asynchrones
  • Repérer les points uniques de défaillance et les dépendances transverses
  • Prédire l'effet d'une panne et raisonner sur l'exploitation

Une architecture de cette taille ne tient pas lisiblement sur un seul schéma : elle se lit en deux vues, celle des flux applicatifs et celle de la plateforme et de l'exploitation. C'est la pratique courante des documents d'architecture, qui découpent le système par point de vue plutôt que de tout superposer. Les deux vues décrivent le même système : l'API de la première vue fait partie des charges applicatives de la seconde, et la base PostgreSQL apparaît dans les deux.

Un client commande depuis son téléphone : la requête traverse un CDN avec pare-feu applicatif, un répartiteur et un ingress, puis une API en trois copies qui lit et écrit ses données et publie deux messages. L'API garde les commandes dans PostgreSQL, répliqué et indexé dans OpenSearch pour la recherche de restaurants ; les sessions et les menus en cache vivent dans Redis, les photos dans un stockage objet. Elle dépose dans RabbitMQ un paiement à faire, que des workers transmettent au prestataire, et publie dans Kafka l'événement « commande validée », lu par un service de notifications. Un ordonnanceur purge chaque nuit les commandes abandonnées.

Vue des flux applicatifs : le client mobile passe en HTTPS par un CDN avec pare-feu applicatif, puis par un répartiteur et un ingress, vers une API de commandes en trois copies. L'API écrit en SQL dans un PostgreSQL primaire, qui se réplique vers une réplique et alimente OpenSearch par indexation ; elle lit les sessions dans Redis, cherche dans OpenSearch et range les photos dans un stockage objet. Elle dépose un paiement à faire dans RabbitMQ, livré à des workers qui appellent le prestataire de paiement en HTTPS, et publie la commande validée dans Kafka, lue par le groupe notifications. Un ordonnanceur purge PostgreSQL chaque nuit.ClientmobileCDNet WAFRépartiteuret ingressAPI commandes3 copiesDonnéesRabbitMQpaiementsKafkacommandesWorkerspaiementServicenotificationsPrestatairede paiementOrdonnanceurpurge nocturnePostgreSQLprimairePostgreSQLrépliqueRedissessions, menusStockage objetphotosOpenSearchrestaurantsréplicationindexationHTTPSHTTPSSQLsessionsrecherchephotospaiement à fairecommande validéelivreHTTPSgroupe notificationspurge
Première vue du capstone : les flux applicatifs d'une plateforme de livraison de repas. Source · SVG
Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 %

Les charges applicatives tournent dans un cluster Kubernetes en région A, avec son DNS interne, et dépendent de services partagés : Keycloak pour les jetons, OpenBao pour les secrets, déverrouillé par le KMS du cloud, et Harbor pour les images. Hors du cluster, une zone d'exploitation porte le bastion avec second facteur, le SIEM et la supervision qui reçoit la télémétrie. La base est copiée chaque nuit, avec son journal en continu, vers une sauvegarde verrouillée en région B.

Vue plateforme et exploitation : dans un cluster Kubernetes en région A, l'API, les workers et les notifications résolvent les noms par un DNS interne ; ils dépendent en pointillé de la clé publique de Keycloak, des secrets d'OpenBao, déverrouillé par le KMS du cloud, et des images de Harbor, regroupés en services partagés. Le cluster envoie sa télémétrie à la supervision et ses journaux de sécurité au SIEM, dans une zone d'exploitation hors cluster où l'administrateur entre par un bastion avec second facteur, dont les sessions vont aussi au SIEM. Les charges écrivent en SQL dans PostgreSQL, copié chaque nuit avec son journal en continu vers une sauvegarde verrouillée en région B.AdministrateurExploitation, hors clusterCluster Kubernetes, région AServices partagésPostgreSQLprimaireKMSdu cloudRégion BBastionMFASIEMSupervisionalertesAPI, workerset notificationsDNSinterneKeycloakOpenBaosecretsHarborregistreSauvegardeverrouilléerésolutionSSH, MFAadministrationclé publiquesecretsdéverrouillageimagestélémétriejournaux de sécuritésessionsSQLchaque nuitjournal en continu
Seconde vue du capstone : la plateforme d'exécution, les services partagés et l'exploitation. Source · SVG
Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 %

Pour chaque question, appliquez la méthode de la formation dans l'ordre : reconnaître la brique, la situer sur le chemin d'une requête ou hors de lui, classer son état, puis raisonner sur sa panne. Le trait rouge dit ce que le client attend ; les flèches pleines vers une file ou un journal marquent l'asynchrone ; les pointillés, les dépendances transverses, dont la panne se révèle souvent au redémarrage. Les zones marquent les domaines de panne et les frontières de confiance.

Les questions sont tirées au hasard dans une banque qui couvre les six modules : reconnaître, classer, suivre les flux, analyser les dépendances, les pannes et l'exploitation. Le seuil de réussite est de 70 %, et la durée indicative de 25 minutes : prenez le temps de relire les deux vues avant de répondre.

Réussir le capstone, c'est savoir lire une architecture ; la concevoir, et installer chacune de ses briques, sont deux capacités qui s'appuient sur celle-ci. Chaque leçon a cité les guides et les formations spécialisées qui prennent le relais : PostgreSQL, Kubernetes, l'observabilité, la gestion des secrets ou les accès d'administration. Le meilleur exercice reste celui de votre propre système : dessinez-le, appliquez-lui la grille, et cherchez ce que votre schéma ne montre pas.

  • Une architecture complète se lit par vues : les flux, puis la plateforme et l'exploitation.
  • Chaque brique se lit par sa famille, sa place sur le chemin et son état.
  • Ce que le client attend casse tout de suite ; ce qui sert au démarrage casse au redémarrage.
  • La sauvegarde vise les sources de vérité, avec ce qui les déverrouille.
  • Chaque brique ajoutée échange un problème contre d'autres.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

15 questions
25 min.
70% requis

Informations

  • Le chronomètre démarre au clic sur Démarrer
  • Questions à choix multiples, vrai/faux et réponses courtes
  • Vous pouvez naviguer entre les questions
  • Les résultats détaillés sont affichés à la fin

Lance le quiz et démarre le chronomètre

Ce projet vous est utile ?

Les guides, formations, quiz et labs restent gratuits. Si vous les utilisez régulièrement, vous pouvez contribuer à leur maintenance et à leur développement.

Devenir membre de soutien (nouvel onglet) Soutenir une fois (nouvel onglet) En savoir plus

Suivez aussi le projet sur LinkedIn