Exemples de modèle C4 : Stripe, Netflix, Uber et Revolut

La plupart des exemples de modèle C4 que l'on trouve portent sur un seul système jouet : une banque, une boutique en ligne, une application de banque en ligne avec trois boîtes et une base de données. Ils montrent la notation. Ils ne montrent pas la partie difficile, qui consiste à décider quoi laisser de côté quand le système réel compte des centaines de services.

Cette page rassemble quatre exemples de modèle C4 plus conséquents, chacun modélisé du contexte jusqu'aux composants : un paiement par carte chez Stripe, une demande de lecture chez Netflix, une demande de course chez Uber et un virement international chez Revolut. Chacun est accompagné de son diagramme de niveau 1, d'un court résumé de la façon dont il zoome aux niveaux 2 et 3, et d'un lien vers l'article complet. À la fin, vous trouverez un petit exemple à copier et une liste de ce que les quatre ont en commun.

Une note sur les sources. Les quatre exemples viennent de notre série « Anatomy of », et chacun repose entièrement sur la communication publique de l'entreprise : blogs d'ingénierie, conférences, dépôts open source, offres d'emploi et études de cas externes. Aucun n'est un document d'architecture officiel de l'entreprise concernée. Chaque article complet indique où les détails sont déduits plutôt qu'affirmés par l'entreprise.

Si le modèle C4 lui-même est nouveau pour vous, lisez d'abord ce qu'est le modèle C4. Les quatre guides par niveau approfondissent chaque type de diagramme : contexte système, conteneurs, composants et code.

Ce qui fait un bon exemple C4

Un exemple de diagramme C4 est utile quand on peut en tirer une décision, pas seulement une forme. Les quatre exemples ci-dessous ont été écrits selon les mêmes règles, et ces règles valent la peine d'être reprises avant de regarder l'un d'eux.

Suivez une seule action utilisateur. Aucun de ces exemples n'essaie de documenter toute l'entreprise. Chacun choisit une seule chose que fait un utilisateur (un paiement, une lecture, une course, un virement) et ne dessine que ce que cette action touche. C'est ce qui ramène un parc de mille services à une page lisible.

Limitez le niveau 1 à une dizaine de boîtes. Au niveau System Context, une entreprise comme Netflix n'est pas un millier de microservices. C'est une poignée de systèmes produit et les acteurs externes qui les entourent. Si votre diagramme de niveau 1 a besoin de quarante boîtes, les frontières sont tracées à la mauvaise hauteur.

Zoomez sur un seul chemin au niveau 2. Le diagramme de conteneurs montre les conteneurs sur le chemin de cette action, avec les technologies et les protocoles. Il ne montre pas tous les conteneurs que l'entreprise exploite.

Choisissez le zoom de niveau 3 pour une raison. Un seul conteneur a droit à un diagramme de composants, et c'est celui où se trouve l'ingénierie intéressante, ou celui que l'entreprise a documenté publiquement avec assez de détails pour le modéliser honnêtement.

Expliquez les boîtes par des décisions. Chaque exemple contient trois courts architecture decision records entre les niveaux. Un diagramme montre ce qui existe. L'ADR dit pourquoi c'est ainsi, et c'est la première question que pose une nouvelle recrue.

Voici comment les quatre se comparent d'un coup d'œil :

Exemple 1 : Stripe, un paiement par carte

D'après la communication publique de Stripe. Pas un document d'architecture officiel de Stripe.

Niveau 1. Au niveau System Context, Stripe n'est pas « une API de paiement ». Notre modèle montre quinze systèmes produit reposant sur un socle commun : Payments, Connect, Billing, Radar, Issuing, Treasury et les autres. Autour d'eux se trouvent les marchands, les porteurs de carte, les réseaux de cartes, les moyens de paiement alternatifs, les banques acquéreuses et émettrices, les partenaires bancaires et AWS.

Niveau 2. Le diagramme de conteneurs ouvre la boîte Payments et suit un appel PaymentIntents.create() : l'API gateway, une couche d'idempotence devant chaque endpoint de modification, la machine à états du PaymentIntent, un coffre-fort de données de carte, le scoring Radar en parallèle, les connecteurs réseau, le registre comptable et la livraison des webhooks.

Niveau 3. Le zoom sur les composants entre dans la couche d'idempotence, parce que c'est la partie de la stack la mieux documentée publiquement : un hacheur de requêtes, un magasin de clés dans PostgreSQL, un exécuteur de phases et un suivi des points de reprise qui permet à une requête rejouée de reprendre là où elle s'était arrêtée.

Ce qu'il faut en retenir. C'est l'exemple à étudier pour les diagrammes de composants. La vue de niveau 3 n'est pas une liste de classes ; c'est une chaîne d'étapes sur laquelle un lecteur peut raisonner (« chaque effet de bord externe se situe entre deux points de reprise »).

Article complet : Anatomy of a Charge : modéliser Stripe en C4.

Exemple 2 : Netflix, une demande de lecture

D'après la communication publique de Netflix. Pas un document d'architecture officiel de Netflix.

Niveau 1. Dix systèmes ressortent de façon constante des contenus publics de Netflix : Member Experience, Content Discovery, Streaming Platform, Open Connect, Studio Engineering, Content Engineering, Data Platform, Cloud Platform, Security et l'Ads Platform. Les acteurs externes incluent les appareils des abonnés, les FAI qui hébergent des appliances Open Connect, AWS, les fournisseurs de DRM, les partenaires de paiement et les studios.

Niveau 2. Le zoom sur les conteneurs ouvre la Streaming Platform et suit une demande de lecture : la Playback API, le service de manifeste, le service de licences pour le DRM, la couche de sécurité des messages, un niveau EVCache et les clusters Cassandra derrière. Le manifeste oriente l'appareil vers une appliance Open Connect, et c'est là que réapparaît la décision de niveau 1 de construire un CDN.

Niveau 3. La vue composants entre dans Cosmos, le pipeline d'encodage vidéo. Il n'est pas sur le chemin de lecture au moment de la requête (l'encodage a lieu à l'ingestion d'un titre), et l'article le dit. Il a été choisi parce que Netflix en a publié assez pour nommer chaque étape : inspection, analyse de complexité, génération de l'échelle d'encodage, encodage, validation et notation de qualité.

Ce qu'il faut en retenir. La démonstration la plus claire de « dix choses, pas mille » au niveau 1, et un bon exemple de la façon d'admettre que le zoom de niveau 3 quitte le chemin suivi.

Article complet : Anatomy of a Play : modéliser Netflix en C4.

Exemple 3 : Uber, une demande de course

D'après la communication publique d'Uber. Pas un document d'architecture officiel d'Uber.

Niveau 1. Au niveau System Context, Uber, ce sont trois plateformes produit (Mobility, Delivery, Freight) posées sur un Marketplace commun, avec en dessous une couche de plateformes Foundation : Maps, Payments, identité et risque, communications, la plateforme de ML, le moteur de workflows, le stockage, le streaming, l'observabilité et le compute. Les acteurs externes incluent les passagers, les chauffeurs, les clients de livraison, les coursiers, les commerçants, les réseaux de paiement, les opérateurs télécoms et les régulateurs municipaux.

Niveau 2. Le zoom sur les conteneurs suit une demande de course dans le chemin de dispatch du Marketplace : l'edge gateway, un orchestrateur de trajets qui exécute chaque course comme une instance de workflow, le moteur de matching, la tarification dynamique, le service d'ETA, l'état des chauffeurs, la couche de stockage et Kafka.

Niveau 3. La vue composants ouvre le moteur de matching : un normaliseur de requêtes qui transforme les coordonnées en index d'hexagones H3, un scanner de l'offre, un expanseur d'anneaux, un classeur de candidats, un solveur d'affectation, le répartiteur de notifications et un chemin de repli.

Ce qu'il faut en retenir. L'exemple de la façon de dessiner une entreprise-plateforme au niveau 1 sans dessiner chaque produit. Le Marketplace commun au centre en dit plus sur l'architecture d'Uber que n'importe quelle liste de services.

Article complet : Anatomy of a Ride : modéliser Uber en C4.

Exemple 4 : Revolut, un virement international

D'après la communication publique de Revolut. Pas un document d'architecture officiel de Revolut.

Niveau 1. La communication publique décrit au moins huit systèmes produit : Retail Banking, Business Banking, FX, Wealth et Trading, Credit, FinCrime, Onboarding et KYC, et le registre central avec son backbone d'événements. Autour d'eux : les réseaux de cartes, les rails de paiement (Faster Payments, SEPA, SWIFT), les banques partenaires, les régulateurs et Google Cloud. Le diagramme rend évidente une chose qu'un organigramme ne montrerait pas : FinCrime reçoit des flèches de chaque produit, il se trouve donc sur le chemin critique de tous.

Niveau 2. Le zoom sur les conteneurs suit un virement de EUR vers GBP dans Retail Banking : les applications mobiles, l'edge API, un orchestrateur de virements avec une machine à états explicite, un registre en partie double sur PostgreSQL, le moteur FX, le pipeline FinCrime, un connecteur par rail de paiement, l'event store et les notifications.

Niveau 3. La vue composants ouvre Sherlock, le moteur antifraude : l'assemblage des features, un magasin de profils en mémoire, le serveur de modèles, une politique de décision, le réentraînement nocturne et une boucle de retour des analystes.

Ce qu'il faut en retenir. C'est l'exemple le plus complet des quatre. Il ajoute une chronologie étape par étape entre les niveaux 1 et 2 (avec des latences clairement indiquées comme illustratives, et non publiées), et une section « à reprendre, à éviter » qui dit quelles décisions une équipe de dix services devrait copier et lesquelles non.

Article complet : Anatomy of a Transfer : modéliser Revolut en C4.

Un petit exemple à copier

Les quatre exemples ci-dessus sont volontairement grands. La plupart des systèmes ne le sont pas, alors voici un petit exemple de modèle C4 sur les trois niveaux utiles : la plateforme e-commerce utilisée tout au long de notre guide complet du modèle C4. Reprenez la forme, renommez les boîtes.

Niveau 1 : System Context

[Client] --> [Plateforme e-commerce] : Parcourt les produits, passe des commandes
[Personnel d'entrepôt] --> [Plateforme e-commerce] : Gère le stock
[Plateforme e-commerce] --> [Payment Gateway (Stripe)] : Traite les paiements
[Plateforme e-commerce] --> [Transporteur (FedEx API)] : Crée les expéditions
[Plateforme e-commerce] --> [Email Service (SendGrid)] : Envoie les notifications

Deux types d'utilisateurs, trois systèmes externes, une boîte pour tout ce qui vous appartient.

Niveau 2 : Container

[Single-Page Application (React)] --> [API Gateway (Kong)] : Appelle l'API (HTTPS/JSON)
[API Gateway] --> [Order Service (Go)] : Route les requêtes
[API Gateway] --> [Product Service (Go)] : Route les requêtes
[API Gateway] --> [User Service (Go)] : Route les requêtes
[Order Service] --> [Order Database (PostgreSQL)] : Lit/écrit les commandes
[Product Service] --> [Product Database (PostgreSQL)] : Lit/écrit les produits
[User Service] --> [User Database (PostgreSQL)] : Lit/écrit les utilisateurs
[Order Service] --> [Message Queue (Kafka)] : Publie les événements de commande
[Notification Service (Go)] --> [Message Queue] : Consomme les événements de commande

Chaque boîte nomme sa technologie, chaque flèche nomme son protocole ou son rôle, et les stockages de données sont dessinés comme des conteneurs.

Niveau 3 : Component (dans l'Order Service)

[Order Handler] --> [Order Service] : Délègue la logique métier
[Order Service] --> [Order Repository] : Persiste les commandes
[Order Service] --> [Payment Client] : Valide le paiement
[Order Service] --> [Inventory Client] : Vérifie la disponibilité du stock
[Order Repository] --> [Order Database (PostgreSQL)] : Requêtes SQL
[Payment Client] --> [Payment Gateway (Stripe)] : HTTPS/REST
[Inventory Client] --> [Product Service] : gRPC

Un seul conteneur a droit à un diagramme de composants, la même règle que suivent les quatre grands exemples. Les services Product et User sont du CRUD simple, dessiner leur intérieur n'apporterait rien que la liste des dossiers ne montre déjà.

Pour le raisonnement derrière chacun de ces choix, voir les guides par niveau : ce qui a sa place dans un diagramme de contexte système, ce qui a sa place dans un diagramme de conteneurs et quand un diagramme de composants vaut la peine d'être dessiné. Nous avons laissé de côté le niveau 4 pour la même raison que la plupart des équipes ; le guide du diagramme de code explique quand il mérite sa place.

Ce que les quatre ont en commun

Mis côte à côte, les quatre exemples suivent la même poignée d'habitudes. Aucune n'est une règle du modèle C4 lui-même. Ce sont elles qui ont rendu ces modèles lisibles.

Une dizaine de boîtes au niveau 1. Quinze pour Stripe, dix pour Netflix, huit pour Revolut, et pour Uber trois plateformes produit sur un Marketplace avec les plateformes Foundation en dessous. Aucune de ces entreprises n'est petite. Les diagrammes de niveau 1 restent petits parce qu'ils regroupent par système produit, pas par service.

Un seul chemin au niveau 2. Chaque diagramme de conteneurs ne montre que les conteneurs traversés par une action. La vue conteneurs de Stripe n'a ni conteneur Billing ni conteneur Atlas. Celle de Netflix ne contient rien de Studio Engineering. Ce n'est pas un oubli ; ces conteneurs ont leur place sur un autre diagramme, pour une autre action.

Un seul conteneur au niveau 3, choisi honnêtement. Le zoom sur les composants va toujours là où la documentation publique est assez détaillée pour dessiner de vrais composants. L'article sur Netflix dit clairement que Cosmos n'est pas sur le chemin de lecture au moment de la requête. Un exemple qui cache ce genre de choix enseigne la mauvaise leçon.

Les systèmes externes pèsent autant que les systèmes internes. Réseaux de cartes, FAI, rails de paiement, opérateurs télécoms : dans les quatre exemples, certaines des boîtes les plus importantes sont des choses que l'entreprise ne possède pas. Les connecteurs de Revolut vers les rails de paiement sont les conteneurs dont elle ne peut pas éliminer les pannes par l'ingénierie, et c'est le diagramme qui le rend visible.

Les décisions sont à côté des boîtes. Chaque exemple compte trois ADR, et chaque ADR explique une boîte qu'un nouvel arrivant trouverait surprenante : pourquoi Netflix a Open Connect là où d'autres services de streaming utilisent un CDN commercial, pourquoi Revolut n'a pas de Kafka, pourquoi Stripe a bâti sur MongoDB plutôt que d'en migrer. Si vous cherchez la méthode pour les rédiger, le guide complet des architecture decision records la couvre.

Chaque boîte a un responsable. Chaque article termine son modèle par une carte de propriété : quelle équipe possède quel système ou quel conteneur. C'est l'étape qui transforme un diagramme en quelque chose dont quelqu'un est responsable de garder la justesse.

Modélisez votre propre système

Vous n'avez besoin ni du volume de Stripe ni du nombre de services d'Uber pour que tout cela s'applique. Les mêmes étapes fonctionnent pour un système de dix services :

1. Choisissez une action utilisateur qui compte : le checkout, l'inscription, ce qui fait sonner l'astreinte à 3 h du matin.
2. Dessinez le niveau 1 avec votre système en une seule boîte, chaque type d'utilisateur et chaque système externe que cette action touche. Visez moins de quinze boîtes.
3. Dessinez le niveau 2 pour cette seule action. Uniquement les conteneurs qu'elle traverse, chacun annoté de sa technologie, chaque flèche annotée d'un verbe et d'un protocole.
4. Choisissez un conteneur pour le niveau 3, celui avec lequel une nouvelle recrue aurait du mal, et dessinez ses principaux composants.
5. Rédigez trois ADR pour les trois boîtes dont quelqu'un demandera « pourquoi c'est comme ça ? ».
6. Mettez un nom d'équipe sur chaque conteneur.

Puis recommencez pour l'action suivante. Après trois ou quatre actions, les diagrammes de niveau 2 commencent à se recouper, et ce recoupement est votre vrai diagramme de conteneurs.

Ce que les quatre exemples ne peuvent pas montrer, c'est ce qui se passe six mois plus tard, quand le code a bougé et que les diagrammes, eux, n'ont pas bougé. C'est le problème autour duquel archyl est construit. Connectez un dépôt et la découverte par IA propose des systèmes, conteneurs, composants et relations que vous validez au lieu de les dessiner de zéro, et un score de dérive vérifie ensuite le modèle par rapport au code pour que vous sachiez quand il est devenu obsolète.

FAQ

Qu'est-ce qu'un bon exemple de modèle C4 ?

Un bon exemple de modèle C4 suit une vraie action utilisateur à travers les niveaux 1 à 3 et explique ses boîtes surprenantes. Les quatre exemples de cette page (Stripe, Netflix, Uber, Revolut) le font chacun, avec un diagramme de niveau 1 d'une dizaine de systèmes, un diagramme de conteneurs limité à un chemin et un zoom sur les composants. Pour un petit système, l'exemple e-commerce ci-dessus est un modèle raisonnable.

Où trouver un exemple de diagramme de conteneurs C4 ?

Chacun des quatre articles complets contient un diagramme de conteneurs de niveau 2 : le cœur des paiements de Stripe, la Streaming Platform de Netflix, le chemin de dispatch d'Uber et le chemin des virements de Revolut. Pour un exemple plus petit et détaillé, avec un tableau des conteneurs et des relations, voir le guide du diagramme de conteneurs C4.

S'agit-il de diagrammes d'architecture officiels de Stripe, Netflix, Uber et Revolut ?

Non. Chaque modèle repose entièrement sur la communication publique de l'entreprise, et chaque article complet indique où les détails sont déduits plutôt qu'affirmés. Ils sont là pour montrer comment le modèle C4 rend une stack complexe lisible, pas pour documenter le fonctionnement actuel de ces entreprises.

Les exemples C4 ont-ils besoin des quatre niveaux ?

Rarement. Les quatre exemples ici dessinent les niveaux 1, 2 et 3 puis s'arrêtent. Les diagrammes de niveau code changent à chaque refactoring et sont généralement mieux générés depuis le code que dessinés, c'est pourquoi la plupart des modèles C4 réels s'arrêtent aux composants.

Combien d'éléments un diagramme de contexte système C4 doit-il avoir ?

Il n'y a pas de limite officielle. Dans ces exemples, le niveau 1 va de huit à quinze systèmes plus leurs acteurs externes, pour des entreprises qui ont des centaines ou des milliers de services. Si le vôtre en demande beaucoup plus, vous dessinez probablement des conteneurs au mauvais niveau, ou il vous faut une vue de paysage système couvrant plusieurs systèmes.

Envie de modéliser votre propre système en C4 ? Essayez archyl gratuitement avec le plan Developer, sans carte bancaire. À lire ensuite : Qu'est-ce que le modèle C4 ? Le guide complet | Guide du diagramme de contexte système C4 | Guide du diagramme de conteneurs C4 | Guide du diagramme de composants C4 | Guide du diagramme de code C4.