C4-Modell Beispiele: Stripe, Netflix, Uber und Revolut

Die meisten C4-Modell-Beispiele, die man findet, sind ein einzelnes Spielzeugsystem: eine Bank, ein Webshop, eine Online-Banking-App mit drei Kästen und einer Datenbank. Sie zeigen die Notation. Sie zeigen nicht den schwierigen Teil, nämlich zu entscheiden, was man weglässt, wenn das reale System Hunderte von Services hat.

Diese Seite versammelt vier größere C4-Modell-Beispiele, jedes vom Kontext bis hinunter zu den Komponenten modelliert: eine Stripe-Kartenzahlung, eine Netflix-Wiedergabeanfrage, eine Uber-Fahrtanfrage und eine grenzüberschreitende Revolut-Überweisung. Jedes kommt mit seinem Diagramm der Ebene 1, einer kurzen Zusammenfassung, wie es auf die Ebenen 2 und 3 zoomt, und einem Link zum vollständigen Beitrag. Am Ende gibt es ein kleines Beispiel zum Kopieren und eine Liste dessen, was die vier gemeinsam haben.

Ein Hinweis zu den Quellen. Alle vier Beispiele stammen aus unserer Reihe „Anatomy of", und jedes basiert ausschließlich auf öffentlichen Informationen des jeweiligen Unternehmens: Engineering-Blogs, Konferenzvorträge, Open-Source-Repositories, Stellenausschreibungen und externe Fallstudien. Keines davon ist ein offizielles Architekturdokument des betreffenden Unternehmens. Jeder vollständige Beitrag kennzeichnet, wo Details abgeleitet und nicht vom Unternehmen selbst angegeben sind.

Wenn das C4-Modell selbst neu für Sie ist, lesen Sie zuerst was das C4-Modell ist. Die vier Leitfäden zu den Ebenen gehen bei jedem Diagrammtyp tiefer: System Context, Container, Component und Code.

Was ein gutes C4-Beispiel ausmacht

Ein C4-Diagramm-Beispiel ist nützlich, wenn man daraus eine Entscheidung lernen kann, nicht nur eine Form. Die vier folgenden Beispiele wurden nach denselben Regeln geschrieben, und diese Regeln lohnt es sich zu übernehmen, bevor Sie sich eines davon ansehen.

Verfolgen Sie eine einzige Benutzeraktion. Keines dieser Beispiele versucht, das ganze Unternehmen zu dokumentieren. Jedes wählt eine einzige Sache, die ein Nutzer tut (eine Zahlung, eine Wiedergabe, eine Fahrt, eine Überweisung), und zeichnet nur, was diese Aktion berührt. Das hält eine Landschaft aus tausend Services auf einer lesbaren Seite.

Halten Sie Ebene 1 bei etwa zehn Kästen. Auf der Ebene System Context besteht ein Unternehmen wie Netflix nicht aus tausend Microservices. Es besteht aus einer Handvoll Produktsystemen und den externen Akteuren um sie herum. Braucht Ihr Diagramm der Ebene 1 vierzig Kästen, sind die Grenzen auf der falschen Höhe gezogen.

Zoomen Sie auf Ebene 2 in einen einzigen Pfad. Das Container-Diagramm zeigt die Container auf dem Pfad dieser einen Aktion, mit Technologien und Protokollen. Es zeigt nicht jeden Container, den das Unternehmen betreibt.

Wählen Sie den Zoom auf Ebene 3 mit Grund. Nur ein Container bekommt ein Komponentendiagramm, und zwar der, in dem das interessante Engineering steckt, oder der, den das Unternehmen öffentlich ausführlich genug dokumentiert hat, um ihn ehrlich zu modellieren.

Erklären Sie die Kästen mit Entscheidungen. Jedes Beispiel enthält zwischen den Ebenen drei kurze Architecture Decision Records. Ein Diagramm zeigt, was existiert. Der ADR sagt, warum es so aussieht, und das ist die Frage, die eine neue Kollegin oder ein neuer Kollege zuerst stellt.

So schneiden die vier im Überblick ab:

Beispiel 1: Stripe, eine Kartenzahlung

Basierend auf öffentlichen Informationen von Stripe. Kein offizielles Architekturdokument von Stripe.

Ebene 1. Auf der Ebene System Context ist Stripe nicht „eine Zahlungs-API". Unser Modell zeigt fünfzehn Produktsysteme auf einem gemeinsamen Fundament: Payments, Connect, Billing, Radar, Issuing, Treasury und die übrigen. Um sie herum stehen Händler, Karteninhaber, die Kartennetzwerke, alternative Zahlungsmethoden, Acquirer- und Issuer-Banken, Bankpartner und AWS.

Ebene 2. Das Container-Diagramm öffnet den Kasten Payments und verfolgt einen einzigen PaymentIntents.create()-Aufruf: das API-Gateway, eine Idempotenz-Schicht vor jedem schreibenden Endpoint, die Zustandsmaschine des PaymentIntent, einen Tresor für Kartendaten, das parallel laufende Radar-Scoring, die Netzwerk-Konnektoren, das Ledger und die Webhook-Zustellung.

Ebene 3. Der Komponenten-Zoom geht in die Idempotenz-Schicht, weil sie der am besten öffentlich dokumentierte Teil des Stacks ist: ein Request-Hasher, ein Key Store in PostgreSQL, ein Phasen-Executor und ein Recovery-Point-Tracker, mit dem ein wiederholter Request dort weitermacht, wo er stehen geblieben ist.

Was man daraus mitnimmt. Das ist das Beispiel, an dem man Komponentendiagramme studieren sollte. Die Sicht auf Ebene 3 ist keine Liste von Klassen, sondern eine Kette von Schritten, über die ein Leser nachdenken kann („jeder externe Seiteneffekt liegt zwischen zwei Recovery Points").

Vollständiger Beitrag: Anatomy of a Charge: Stripe im C4-Modell.

Beispiel 2: Netflix, eine Wiedergabeanfrage

Basierend auf öffentlichen Informationen von Netflix. Kein offizielles Architekturdokument von Netflix.

Ebene 1. Zehn Systeme ergeben sich durchgängig aus dem öffentlichen Material von Netflix: Member Experience, Content Discovery, Streaming Platform, Open Connect, Studio Engineering, Content Engineering, Data Platform, Cloud Platform, Security und die Ads Platform. Zu den externen Akteuren gehören Endgeräte der Mitglieder, ISPs, die Open-Connect-Appliances hosten, AWS, DRM-Anbieter, Zahlungspartner und Filmstudios.

Ebene 2. Der Container-Zoom öffnet die Streaming Platform und verfolgt eine Wiedergabeanfrage: die Playback API, den Manifest-Service, den License-Service für DRM, die Message-Security-Schicht, eine EVCache-Stufe und die Cassandra-Cluster dahinter. Das Manifest verweist das Gerät auf eine Open-Connect-Appliance, und hier taucht die Entscheidung aus Ebene 1, ein eigenes CDN zu bauen, wieder auf.

Ebene 3. Die Komponentensicht geht in Cosmos, die Pipeline für Video-Encoding. Sie liegt zum Zeitpunkt der Anfrage nicht auf dem Wiedergabepfad (das Encoding findet statt, wenn ein Titel eingespielt wird), und der Beitrag sagt das auch. Sie wurde gewählt, weil Netflix genug darüber veröffentlicht hat, um jeden Schritt zu benennen: Inspektion, Komplexitätsanalyse, Ladder-Generierung, Encoding, Validierung und Qualitätsbewertung.

Was man daraus mitnimmt. Die klarste Demonstration von „zehn Dingen, nicht tausend" auf Ebene 1, und ein gutes Beispiel dafür, offen zuzugeben, wenn der Zoom auf Ebene 3 den verfolgten Pfad verlässt.

Vollständiger Beitrag: Anatomy of a Play: Netflix im C4-Modell.

Beispiel 3: Uber, eine Fahrtanfrage

Basierend auf öffentlichen Informationen von Uber. Kein offizielles Architekturdokument von Uber.

Ebene 1. Uber besteht auf der Ebene System Context aus drei Produktplattformen (Mobility, Delivery, Freight) auf einem gemeinsamen Marketplace, darunter eine Schicht von Foundation-Plattformen: Maps, Payments, Identität und Risiko, Kommunikation, die ML-Plattform, die Workflow-Engine, Storage, Streaming, Observability und Compute. Zu den externen Akteuren gehören Fahrgäste, Fahrer, Besteller, Kuriere, Händler, Zahlungsnetzwerke, Telekommunikationsanbieter und städtische Regulierungsbehörden.

Ebene 2. Der Container-Zoom verfolgt eine Fahrtanfrage durch den Dispatch-Pfad des Marketplace: das Edge-Gateway, einen Trip-Orchestrator, der jede Fahrt als Workflow-Instanz ausführt, die Matching-Engine, dynamische Preisgestaltung, den ETA-Service, den Fahrerstatus, die Storage-Schicht und Kafka.

Ebene 3. Die Komponentensicht öffnet die Matching-Engine: einen Request-Normalizer, der Koordinaten in H3-Hexagon-Indizes umwandelt, einen Supply-Scanner, einen Ring-Expander, einen Candidate-Ranker, einen Assignment-Solver, den Notification-Dispatcher und einen Fallback-Pfad.

Was man daraus mitnimmt. Das Beispiel dafür, wie man ein Plattformunternehmen auf Ebene 1 zeichnet, ohne jedes Produkt zu zeichnen. Der gemeinsame Marketplace in der Mitte sagt mehr über Ubers Architektur aus als jede Liste von Services.

Vollständiger Beitrag: Anatomy of a Ride: Uber im C4-Modell.

Beispiel 4: Revolut, eine grenzüberschreitende Überweisung

Basierend auf öffentlichen Informationen von Revolut. Kein offizielles Architekturdokument von Revolut.

Ebene 1. Öffentliche Informationen beschreiben mindestens acht Produktsysteme: Retail Banking, Business Banking, FX, Wealth und Trading, Credit, FinCrime, Onboarding und KYC sowie das Core Ledger mit seinem Event-Backbone. Um sie herum: Kartennetzwerke, Zahlungsverkehrssysteme (Faster Payments, SEPA, SWIFT), Partnerbanken, Aufsichtsbehörden und Google Cloud. Das Diagramm macht etwas offensichtlich, was ein Organigramm nicht zeigen würde: FinCrime hat Pfeile von jedem Produkt, liegt also auf dem kritischen Pfad aller Produkte.

Ebene 2. Der Container-Zoom verfolgt eine Überweisung von EUR nach GBP durch Retail Banking: die mobilen Apps, die API-Edge, einen Transfer-Orchestrator mit expliziter Zustandsmaschine, ein Double-Entry-Ledger auf PostgreSQL, die FX-Engine, die FinCrime-Pipeline, einen Konnektor pro Zahlungsverkehrssystem, den Event Store und Benachrichtigungen.

Ebene 3. Die Komponentensicht öffnet Sherlock, die Engine zur Betrugserkennung: Feature-Aufbereitung, einen In-Memory-Profile-Store, den Model-Server, eine Entscheidungs-Policy, nächtliches Retraining und eine Feedback-Schleife mit Analysten.

Was man daraus mitnimmt. Das vollständigste der vier Beispiele. Es ergänzt zwischen den Ebenen 1 und 2 eine Schritt-für-Schritt-Zeitleiste (mit Latenzen, die klar als illustrativ und nicht als veröffentlicht gekennzeichnet sind) und einen Abschnitt „übernehmen oder weglassen", der sagt, welche Entscheidungen ein Team mit zehn Services kopieren sollte und welche nicht.

Vollständiger Beitrag: Anatomy of a Transfer: Revolut im C4-Modell.

Ein kleines Beispiel zum Kopieren

Die vier Beispiele oben sind absichtlich groß. Die meisten Systeme sind es nicht, deshalb hier ein kleines C4-Modell-Beispiel auf allen drei sinnvollen Ebenen: die E-Commerce-Plattform, die in unserem vollständigen Leitfaden zum C4-Modell durchgängig verwendet wird. Übernehmen Sie die Form, benennen Sie die Kästen um.

Ebene 1: System Context

[Kunde] --> [E-Commerce-Plattform] : Durchsucht Produkte, gibt Bestellungen auf
[Lagerpersonal] --> [E-Commerce-Plattform] : Verwaltet den Bestand
[E-Commerce-Plattform] --> [Payment Gateway (Stripe)] : Verarbeitet Zahlungen
[E-Commerce-Plattform] --> [Versanddienstleister (FedEx API)] : Erstellt Sendungen
[E-Commerce-Plattform] --> [Email Service (SendGrid)] : Versendet Benachrichtigungen

Zwei Arten von Nutzern, drei externe Systeme, ein Kasten für alles, was Ihnen gehört.

Ebene 2: Container

[Single-Page Application (React)] --> [API Gateway (Kong)] : Ruft die API auf (HTTPS/JSON)
[API Gateway] --> [Order Service (Go)] : Leitet Requests weiter
[API Gateway] --> [Product Service (Go)] : Leitet Requests weiter
[API Gateway] --> [User Service (Go)] : Leitet Requests weiter
[Order Service] --> [Order Database (PostgreSQL)] : Liest/schreibt Bestellungen
[Product Service] --> [Product Database (PostgreSQL)] : Liest/schreibt Produkte
[User Service] --> [User Database (PostgreSQL)] : Liest/schreibt Benutzer
[Order Service] --> [Message Queue (Kafka)] : Veröffentlicht Bestell-Events
[Notification Service (Go)] --> [Message Queue] : Konsumiert Bestell-Events

Jeder Kasten nennt seine Technologie, jeder Pfeil sein Protokoll oder seinen Zweck, und die Datenspeicher sind als Container gezeichnet.

Ebene 3: Component (im Order Service)

[Order Handler] --> [Order Service] : Delegiert die Geschäftslogik
[Order Service] --> [Order Repository] : Speichert Bestellungen
[Order Service] --> [Payment Client] : Validiert die Zahlung
[Order Service] --> [Inventory Client] : Prüft die Verfügbarkeit
[Order Repository] --> [Order Database (PostgreSQL)] : SQL-Abfragen
[Payment Client] --> [Payment Gateway (Stripe)] : HTTPS/REST
[Inventory Client] --> [Product Service] : gRPC

Nur ein Container bekommt ein Komponentendiagramm, dieselbe Regel, der die vier großen Beispiele folgen. Product und User Service sind einfaches CRUD, ihr Inneres zu zeichnen würde nichts hinzufügen, was ein Ordnerlisting nicht schon zeigt.

Die Begründung hinter jeder dieser Entscheidungen finden Sie in den Leitfäden zu den Ebenen: was in ein System-Context-Diagramm gehört, was in ein Container-Diagramm gehört und wann sich ein Komponentendiagramm lohnt. Ebene 4 haben wir hier aus demselben Grund weggelassen wie die meisten Teams; der Leitfaden zum Code-Diagramm erklärt, wann sie ihren Platz verdient.

Was die vier gemeinsam haben

Nebeneinandergelegt folgen die vier Beispiele denselben wenigen Gewohnheiten. Keine davon ist eine Regel des C4-Modells selbst. Sie sind es, die diese Modelle lesbar gemacht haben.

Rund zehn Kästen auf Ebene 1. Fünfzehn bei Stripe, zehn bei Netflix, acht bei Revolut, und bei Uber drei Produktplattformen auf einem Marketplace mit den Foundation-Plattformen darunter. Keines dieser Unternehmen ist klein. Die Diagramme der Ebene 1 bleiben klein, weil sie nach Produktsystem gruppieren, nicht nach Service.

Ein Pfad auf Ebene 2. Jedes Container-Diagramm zeigt nur die Container, die eine Aktion durchläuft. Die Container-Sicht von Stripe hat keine Billing- oder Atlas-Container. Die von Netflix enthält nichts aus Studio Engineering. Das ist keine Auslassung; diese Container gehören in ein anderes Diagramm für eine andere Aktion.

Ein Container auf Ebene 3, ehrlich gewählt. Der Komponenten-Zoom geht immer dorthin, wo die öffentliche Dokumentation tief genug ist, um echte Komponenten zu zeichnen. Der Netflix-Beitrag sagt offen, dass Cosmos zum Zeitpunkt der Anfrage nicht auf dem Wiedergabepfad liegt. Ein Beispiel, das eine solche Entscheidung verschweigt, lehrt das Falsche.

Externe Systeme wiegen so viel wie interne. Kartennetzwerke, ISPs, Zahlungsverkehrssysteme, Telekommunikationsanbieter: In allen vier Beispielen sind einige der wichtigsten Kästen Dinge, die dem Unternehmen nicht gehören. Revoluts Konnektoren zu den Zahlungsverkehrssystemen sind die Container, deren Ausfall es nicht wegentwickeln kann, und das Diagramm macht das sichtbar.

Entscheidungen stehen neben den Kästen. Jedes Beispiel hat drei ADRs, und jeder ADR erklärt einen Kasten, den ein Neuling überraschend fände: warum Netflix Open Connect hat, wo andere Streamingdienste ein kommerzielles CDN nutzen, warum Revolut kein Kafka hat, warum Stripe auf MongoDB aufgebaut hat, statt davon wegzumigrieren. Wenn Sie die Methode suchen, um solche Entscheidungen festzuhalten, behandelt sie der vollständige Leitfaden zu Architecture Decision Records.

Jeder Kasten hat einen Owner. Jeder Beitrag schließt sein Modell mit einer Ownership-Map ab: welches Team welches System oder welchen Container verantwortet. Das ist der Schritt, der aus einem Diagramm etwas macht, für dessen Richtigkeit jemand verantwortlich ist.

Modellieren Sie Ihr eigenes System

Sie brauchen weder das Volumen von Stripe noch die Service-Anzahl von Uber, damit all das gilt. Dieselben Schritte funktionieren für ein System mit zehn Services:

1. Wählen Sie eine Benutzeraktion, die wichtig ist: den Checkout, die Registrierung, das, was um 3 Uhr morgens jemanden per Pager weckt.
2. Zeichnen Sie Ebene 1 mit Ihrem System als einem Kasten, jeder Art von Nutzer und jedem externen System, das diese Aktion berührt. Ziel: weniger als fünfzehn Kästen.
3. Zeichnen Sie Ebene 2 für diese eine Aktion. Nur die Container, die sie durchläuft, jeder mit seiner Technologie beschriftet, jeder Pfeil mit einem Verb und einem Protokoll.
4. Wählen Sie einen Container für Ebene 3, den, mit dem sich eine neue Person schwertun würde, und zeichnen Sie seine wichtigsten Komponenten.
5. Schreiben Sie drei ADRs für die drei Kästen, bei denen jemand fragen wird: „Warum ist das so?"
6. Schreiben Sie an jeden Container einen Teamnamen.

Wiederholen Sie das dann für die nächste Aktion. Nach drei oder vier Aktionen beginnen sich die Diagramme der Ebene 2 zu überschneiden, und diese Überschneidung ist Ihr eigentliches Container-Diagramm.

Was die vier Beispiele nicht zeigen können, ist, was sechs Monate später passiert, wenn sich der Code bewegt hat und die Diagramme nicht. Um genau dieses Problem herum ist archyl gebaut. Verbinden Sie ein Repository, und die KI-Erkennung schlägt Systeme, Container, Komponenten und Beziehungen vor, die Sie freigeben, statt sie von Grund auf zu zeichnen, und ein Drift-Score prüft das Modell danach gegen den Code, damit Sie erfahren, wann es veraltet ist.

FAQ

Was ist ein gutes Beispiel für ein C4-Modell?

Ein gutes C4-Modell-Beispiel verfolgt eine reale Benutzeraktion über die Ebenen 1 bis 3 und erklärt seine überraschenden Kästen. Die vier Beispiele auf dieser Seite (Stripe, Netflix, Uber, Revolut) tun genau das, mit einem Diagramm der Ebene 1 von rund zehn Systemen, einem auf einen Pfad begrenzten Container-Diagramm und einem Komponenten-Zoom. Für ein kleines System ist das E-Commerce-Beispiel oben eine sinnvolle Vorlage.

Wo finde ich ein Beispiel für ein C4-Container-Diagramm?

Jeder der vier vollständigen Beiträge hat ein Container-Diagramm der Ebene 2: den Payments-Kern von Stripe, die Streaming Platform von Netflix, den Dispatch-Pfad von Uber und den Überweisungspfad von Revolut. Ein kleineres durchgearbeitetes Beispiel mit einer Tabelle der Container und Beziehungen finden Sie im Leitfaden zum C4-Container-Diagramm.

Sind das offizielle Architekturdiagramme von Stripe, Netflix, Uber und Revolut?

Nein. Jedes Modell basiert ausschließlich auf öffentlichen Informationen des jeweiligen Unternehmens, und jeder vollständige Beitrag kennzeichnet, wo Details abgeleitet und nicht angegeben sind. Sie sollen zeigen, wie das C4-Modell einen komplexen Stack lesbar macht, nicht dokumentieren, wie diese Unternehmen heute arbeiten.

Brauchen C4-Beispiele alle vier Ebenen?

Selten. Alle vier Beispiele hier zeichnen die Ebenen 1, 2 und 3 und hören dann auf. Diagramme auf Code-Ebene ändern sich mit jedem Refactoring und werden meist besser aus dem Code erzeugt als gezeichnet, deshalb enden die meisten realen C4-Modelle bei den Komponenten.

Wie viele Elemente sollte ein C4-System-Context-Diagramm haben?

Es gibt keine offizielle Grenze. In diesen Beispielen umfasst Ebene 1 acht bis fünfzehn Systeme plus ihre externen Akteure, bei Unternehmen mit Hunderten oder Tausenden von Services. Braucht Ihres deutlich mehr, zeichnen Sie wahrscheinlich Container auf der falschen Ebene, oder Sie brauchen eine System-Landscape-Sicht über mehrere Systeme.

Möchten Sie Ihr eigenes System im C4-Modell modellieren? Testen Sie archyl kostenlos im Developer-Plan, ohne Kreditkarte. Weiterlesen: Was ist das C4-Modell? Ein vollständiger Leitfaden | Leitfaden zum C4-System-Context-Diagramm | Leitfaden zum C4-Container-Diagramm | Leitfaden zum C4-Komponentendiagramm | Leitfaden zum C4-Code-Diagramm.