Haftungsausschluss. Dieser Artikel basiert vollständig auf Ubers öffentlichen Mitteilungen — ihrem Engineering-Blog, Konferenzvorträgen, Open-Source-Repositorys und externen Fallstudien. Es ist kein offizielles Uber-Architekturdokument. Wir modellieren das, was wir öffentlich wissen, um zu illustrieren, wie ein Stack mit viertausend Services mit dem C4-Modell lesbar gemacht werden kann. Wo Details abgeleitet statt von Uber genannt sind, sagen wir es.

Anatomie einer Fahrt: Uber in C4 mit Archyl modellieren

Ein Fahrgast tippt UberX bestellen um 19:23 Uhr an einem regnerischen Freitag in Manhattan. Acht Sekunden später hat ein Fahrer 0,4 Meilen entfernt die Fahrt akzeptiert, ein ETA wurde berechnet und gerendert, der Tarif ist verriegelt, die Zahlung vorautorisiert und ein latenzarmer Echtzeit-Kanal ist zwischen Fahrgast und Fahrer offen. Bis er vom Telefon aufschaut, ist das Auto bereits unterwegs.

Dieser einzelne Tap, mehr als 30 Millionen Mal pro Tag in 600+ Städten wiederholt, durchquert dutzende Uber-Systeme und drei externe Netzwerke, bevor das erste Frame jemals auf dem Display des Fahrers landet.

2024 betrieb Ubers Stack rund 4.000 Microservices, lieferte Spitzen von weit über einer Million Requests pro Sekunde an mobile Clients, schedulte Compute auf seinem eigenen Cluster-Manager, persistierte Zustand in seiner eigenen MySQL-abgeleiteten Storage-Schicht, indizierte den Planeten auf seinem eigenen hexagonalen Raster, orchestrierte Millionen von Trip-Workflows auf seiner eigenen State-Machine-Engine und trainierte ETA-Modelle auf seiner eigenen ML-Plattform.

Wie versteht man einen Stack mit so vielen beweglichen Teilen? Wie bei Stripe und Netflix tut man das nicht — nicht alles auf einmal. Genau dafür wurde das C4-Modell erfunden.

In diesem Beitrag verfolgen wir eine einzige Benutzeraktion — eine Fahrtanforderung vom Tap bis zur Fahrer-Akzeptanz — und beobachten, wie sie Ubers Architektur über die vier C4-Ebenen durchquert. Wir decken nicht jedes Produkt ab; wir verfolgen eine Fahrt, schreiben die ADRs, die die getroffenen Entscheidungen erklären, und enden mit einer Karte der Teams, die jede Box besitzen. Unterwegs touren wir durch jede Archyl-Funktion, die diese Art von Modell — und die Policies darum — wirklich wartbar macht.

Ebene 1 — Systemkontext: drei Plattformen, ein Marketplace

Auf Systemkontext-Ebene ist Uber keine „Fahrdienst-App". Es sind drei Produktplattformen, die auf einem geteilten Marketplace und einem Stack von übergreifenden Foundation-Systemen sitzen:

1. Mobility — UberX, Uber Black, Uber Pool, Uber Reserve, Comfort, SUV, Premier, Taxi-Partnerschaften
2. Delivery — Uber Eats (Essen), Uber Direct (Drittanbieter-Lieferung-as-a-Service), Postmates, Alkohol, Lebensmittel
3. Freight — Langstrecken-Trucking, Uber Freight Loadbuilder, Broker-Tools

Darunter ist die Marketplace-Plattform das eigentliche Gehirn — die Matching-Engine, der Dispatch-Optimierer, das dynamische Preissystem, die Angebot/Nachfrage-Forecaster. Marketplace ist das, was eine Fahrtanforderung zu einer Fahrt macht.

Darunter sitzen die Foundation-Plattformen: Maps (Routing, ETA, Distanz/Dauer-Matrizen, Verkehr), Payments, Identity & Risk, Communications (Push, SMS, In-App-Messaging), Notifications, die ML-Plattform (Michelangelo), die Workflow-Engine (Cadence/Temporal), die Storage-Plattformen (Schemaless, Docstore, Cassandra, RocksDB-basierte Stores), die Streaming-Plattformen (Kafka, uReplicator, Flink), der Observability-Stack (M3 Metrics, Jaeger Tracing, ELK Logs) und die Compute-Plattform (historisch Mesos + Aurora → Peloton → heute Kubernetes-basiert).

Drumherum die externen Akteure: Fahrgäste, Fahrer, Esser, Kuriere, Händler, Verlader und Spediteure, Kartenanbieter (eigene + Drittanbieter als Fallback), Zahlungsnetzwerke und Acquiring-Banken, Identitäts-Verifizierungsanbieter, Telekom-Anbieter für SMS und Sprache, Cloud-Anbieter (Uber läuft hybrid: eigene Rechenzentren + AWS/GCP für spezifische Workloads) und Regulatoren auf Stadtebene.

Drei Produktplattformen. Ein Marketplace. Zehn Foundation-Plattformen. Alles andere ist Detail.

Das ist das Geschenk von Ebene 1: Im Systemkontext müssen Sie nicht wissen, dass Mobility zweihundert Microservices sind. Sie müssen wissen, dass es existiert, dass es mit Marketplace spricht, dass Marketplace mit Maps spricht und dass Cadence den langen Trip-Workflow darunter orchestriert. Das Diagramm ist ein Gesprächsstarter, kein Inventar.

Archyl-Funktion im Einsatz. Ein Systemkontext-Diagramm in Archyl ist eine einzelne C4 Level 1-Ansicht mit Auto-Layout, Click-Through-Navigation in Container und Overlays, mit denen Sie Teilmengen stummschalten/hervorheben können (z. B. „nur Foundation-Plattformen zeigen"). Externe Akteure sind erstklassige C4-Elemente mit eigenem Typ, sodass sie distinkt gerendert werden.

ADR-001 · H3-Hexagon-Raster für geospatiale Indexierung

Status · Akzeptiert (2018, open-sourced; weiterhin aktiv 2026)

Kontext · Marketplaces Matching-Engine muss „welche Fahrer sind in der Nähe dieses Fahrgasts?" in Millisekunden bei stadtweiter Concurrency beantworten und gleichzeitig Analysen wie Surge-Zonen, ETAs und Angebotsforecasting unterstützen. Die klassischen Optionen waren rechteckige Raster (Z-Order, Geohash, S2-Zellen von Google), aber Rechtecke haben einen fundamentalen Fehler für diesen Bereich: jedes Rechteck hat mehr als eine Nachbar-Distanz — Ecken sind weiter als Kanten, was ungleiche Distanzapproximationen und asymmetrische „Was ist in der Nähe"-Abfragen produziert.

Entscheidung · Den Planeten stattdessen in Hexagonen kacheln. Ein hierarchisches Hexagon-Raster (H3) mit sechzehn Auflösungen vom Kontinent-Maßstab bis ~1 m² bauen. Jedes Hexagon hat sechs gleich weit entfernte Nachbarn, was Nächste-Nachbarn- und Ring-Abfragen symmetrisch und schnell macht. Die Bibliothek open-sourcen, damit Partner und Uber-Ingenieure dasselbe Raster teilen.

Konsequenzen · H3 wurde Ubers räumliches Primitive über Marketplace, Maps, ETA, Surge und Analytics. Derselbe H3Index wird in Dispatch-Hot-Paths und in Offline-Forecasting-Jobs verwendet. Es ist auch eines von Ubers erfolgreichsten Open-Source-Projekten — wird von Foursquare, DoorDash, AT&T und unzähligen Geo-Startups verwendet. Die wenigen Fälle, in denen Hexagone nicht sauber kacheln (die 12 fünfeckigen Anker des Ikosaeders), sind dokumentiert und im Produktionscode vermieden.

In Archyl ist das, wie ein ADR seinen Platz verdient: er erklärt, warum die Grenze so aussieht. Klicken Sie auf jeden Container, der geospatialen Zustand berührt, und der H3-ADR ist einen Klick entfernt.

Archyl-Funktion im Einsatz. ADRs in Archyl sind erstklassige Aufzeichnungen, die mit spezifischen C4-Elementen verknüpft sind. Sie erscheinen als Karten auf den relevanten Boxen, sind nach Status filterbar (proposed, accepted, deprecated, superseded) und werden als YAML in Git versendet, sodass sie neben dem Code leben. Wenn jemand 2030 vorschlägt, H3 zu ersetzen, taucht der bestehende ADR automatisch als verwandter Kontext auf.

Ebene 2 — Container: Zoom in Marketplaces Dispatch-Pfad

Der Tap des Fahrgasts landet am API-Edge. Öffnen wir die Box.

Der Dispatch-Pfad durchquert ungefähr die folgenden Container:

• Edge Gateway — historisch TChannel + Thrift IDL, heute ein gRPC + HTTP/2-Edge für mobile Clients. Auth, Rate Limiting, Request Shaping und Routing.
• Trip Orchestrator — läuft als langlebiger Cadence/Temporal-Workflow. Die Fahrt ist eine Workflow-Instanz mit deterministischen Zustandsübergängen: requested → matched → arriving → on-trip → completed. Idempotente Retries und Timer-getriebene Eskalationen sind eingebaute Primitives, kein Bespoke-Code.
• Matching-Engine (DISCO) — der eigentliche Marketplace-Optimierer. Gegeben eine Fahrgastanforderung und das Live-Fahrer-Angebot innerhalb weniger H3-Ring-Distanzen, löst er bei jedem Tick ein Constrained-Assignment-Problem.
• Dynamic-Pricing-Service — kombiniert Echtzeit-Angebot/Nachfrage-Signale, um Surge-Multiplikatoren pro H3-Zelle zu berechnen. Gibt ein Fare-Quote aus, das zum Anforderungszeitpunkt verriegelt wird.
• ETA-Service — speist Maps + ML-Modelle für Route, Verkehr und Ankunftsvorhersage. Ubers ETA-Modelle wechselten um 2018 zu Deep Learning und wurden seitdem jedes Jahr verfeinert.
• Maps-Plattform — Ubers hauseigene Routing-Engine, Distance-Matrix-Service und Verkehrs-Ingestion-Pipeline. Fällt in ausgewählten Märkten auf externe Kartenanbieter zurück.
• Driver-State-Service — verfolgt den aktuellen Zustand jedes Fahrers (offline, online, on-trip), Standort und Akzeptanzverhalten. Liest/schreibt Hot-Path-Standortdaten über benutzerdefinierte Geo-Stores.
• Schemaless / Docstore — Ubers MySQL-gestützter sharded Storage. Schemaless ist der ältere; Docstore ist der neuere, multi-region transaktionale Nachfolger. Trip-Zustand, Zahlungen, Benutzerprofile und die meisten Line-of-Business-Daten leben hier.
• Kafka-Cluster — jeder Zustandsübergang emittiert ein Event. Marketplace abonniert für Analytics; nachgelagerte Services abonnieren für Fanout (Notifications, Fraud, Buchhaltung).
• Echtzeit-Kanal — sobald gematcht, ein latenzarmer bidirektionaler Kanal zwischen Fahrgast- und Fahrer-Apps für Standort-Updates und Chat. Unterstützt durch Long-Poll/WebSocket-Gateways und Kafka darunter.

Der Tech-Stack auf dieser Ebene: Go für die meisten neuen High-Throughput-Services, Java in älterem Marketplace-Code, Python in ML-Pipelines und Ops-Skripten, Node.js auf einigen Edge-Schichten, gRPC als modernes RPC-Protokoll (TChannel/Thrift war der Vorgänger), Cassandra und Redis für Hot-Path-Latenz, MySQL unter Schemaless/Docstore, Hadoop/HDFS/Hive/Presto für das Data Warehouse, Spark/Flink für Batch- und Streaming-Compute.

Eine typische Fahrtanforderung berührt Edge Gateway → Trip Orchestrator (Cadence) → Matching Engine (DISCO mit H3-Ring-Abfragen gegen Driver State) → Dynamic Pricing → ETA → Notifications-Fanout (Push an Fahrer) → Driver-Accept-Callback → Echtzeit-Kanal etabliert. All das, mit Retries, end-to-end instrumentiert via Jaeger und gemessen via M3.

Archyl-Funktion im Einsatz. Container-Level-Diagramme zeigen jeden Container, seinen Typ (api / service / database / message_queue / cache / worker / gateway / library / infrastructure), seine Technologien (gezogen aus einem organisationsweiten Technologiekatalog) und seine Beziehungen mit Labels. API-Verträge können an jeden Container angehängt und inline gerendert werden — Uber würde das gRPC .proto für die Trip-Orchestrierung direkt mit dem Trip-Orchestrator-Container verknüpfen.

ADR-002 · Cadence (Temporal) — eine Workflow-Engine bauen, statt stateful Microservices anzuhäufen

Status · Akzeptiert (~2017, als Cadence open-sourced; als Temporal ausgegliedert)

Kontext · 2017 hatte Uber hunderte von Microservices, die langlebige, stateful Geschäftsprozesse implementierten — Fahrten, Bestellungen, Anmeldeflows, Fahrer-Onboarding, Fraud-Reviews. Jeder hatte seine eigene Ad-hoc-State-Machine mit Timern, Retries, Idempotenz und Recovery-Code gewachsen. Ergebnis: jedes Team zahlte die Distributed-Systems-Steuer, und Outages kamen häufig aus subtilen Bugs in Retry/Timeout-Logik.

Entscheidung · Nicht jedes Team bitten, eine State-Machine zu erfinden. Eine generische Workflow-Engine mit deterministischem Replay, dauerhaften Timern, automatischen Retries, Signal-Handling und einem Programmiermodell bauen, in dem Workflow-Code wie sequenzielle Geschäftslogik liest. Als Cadence open-sourcen. Trips, Anmeldung, Fraud-Reviews und Money-Movement-Workflows über mehrere Jahre dorthin migrieren.

Konsequenzen · Cadence (und sein Temporal-Fork, jetzt innerhalb und außerhalb von Uber verwendet) ist nun das Substrat für jeden langlebigen stateful Flow bei Uber. Die „Trip ist ein Workflow"-Abstraktion kollabiert tausende Zeilen bespoke Retry-Code in eine Handvoll wohl-typisierter Activities. Die Engine wurde auch eines der am meisten adoptierten Open-Source-Workflow-Projekte der Branche. Die path-dependent-Lektion: Wenn zehn Teams unabhängig dasselbe Primitive neu implementieren, baut das Primitive.

Archyl-Funktion im Einsatz. Entscheidungen wie Cadence wirken sich über das Modell aus. In Archyl kann ein ADR mehrere C4-Elemente gleichzeitig verknüpfen — eine Entscheidung, viele betroffene Boxen. Eine Suche nach „Workflow" über das Modell deckt jeden als Cadence-Consumer annotierten Container auf.

Ebene 3 — Komponente: in der Matching-Engine

Von allen Komponenten in Ubers Stack ist die Matching-Engine — intern DISCO — die am besten dokumentierte in Konferenzvorträgen und Engineering-Posts.

Eine einzelne Fahrtanforderung durchquert, sobald sie die Matching-Engine erreicht, diese Komponenten:

1. Request Normalizer — wandelt die Koordinaten des Fahrgasts in einen H3-Index in mehreren Auflösungen um (typischerweise res 9 für Hot-Path, res 6 für Ring-Expansion).
2. Supply Scanner — fragt den Live-Fahrer-State-Index für alle berechtigten Fahrer innerhalb eines initialen H3-Rings (~500 m) ab. Filtert nach Fahrzeugtyp, Akzeptanzrate des Fahrers und kürzlichem Decline-Verhalten.
3. Ring Expander — wenn keine berechtigten Fahrer im inneren Ring existieren, nach außen in konzentrischen H3-Ringen expandieren, bis ein Kandidaten-Set sich bildet oder eine Max-Distance-Grenze erreicht wird. Uber hat mehrere Iterationen dieser Expansionsstrategie veröffentlicht, einschließlich ML-getriebener Expansion, die wahrscheinliche Fahrerpfade vorhersagt.
4. Candidate Ranker — bewertet jeden Kandidaten auf ETA-zur-Abholung, Marketplace-Effizienz (wollen wir diesen Fahrer in dieser Nachbarschaft halten?) und historische Akzeptanzwahrscheinlichkeit für dieses Fahrgast/Fahrer-Paar.
5. Assignment Solver — formuliert das Matching-Problem als constrained Optimierung über den lokalen Angebotspool. Der Solver läuft kontinuierlich und batched nahe Anforderungen statt sich auf greedy-first-best-match festzulegen.
6. Notification Dispatcher — sendet dem gematchten Kandidaten eine Push-Notification mit kurzem Akzeptanzfenster. Zeichnet Akzeptanz/Decline zurück in Driver-State auf.
7. Fallback-Pfad — bei Solver-Timeout oder keinen berechtigten Kandidaten, Retry mit gelockerten Constraints (breitere Fahrzeugtypen, längere ETA) oder Eskalation zu Surge.

Das Pattern ist brutal einfach, sobald man es sieht: jede räumliche Abfrage ist ein H3-Ring; jede Geschäftsentscheidung ist ein bewerteter Kandidat; jeder Match ist der Output eines globalen Solver-Runs, keine lokale greedy Entscheidung. Diese Form eliminiert eine ganze Klasse von „Erster-Fahrer-schnappt-Fahrt"-Anti-Patterns, die naive Dispatch-Systeme plagen.

So sieht Komponenten-Level-C4 aus: nicht „hier ist Code", sondern „hier ist die Kette geschäftsbedeutsamer Primitives, jedes besessen, jedes ersetzbar, jedes messbar".

Archyl-Funktion im Einsatz. Komponentendiagramme zeigen, wie ein Container gebaut ist. Jede Komponente hat einen Typ (controller / service / repository / handler / module / job / workflow / activity / entity), einen Dateipfad, Owner und Technologien. Komponenten setzen sich zu einem User Flow zusammen — Archyls Flow-Funktion erlaubt es, die Reise des Fahrgasts als geordnete Sequenz von Komponenten-Invocations zu autoreren und als Schritt-für-Schritt-Diagramm zu rendern.

ADR-003 · Schemaless und Docstore — die Storage-Schicht besitzen statt kaufen

Status · Akzeptiert (Schemaless: ~2014; Docstore: ~2020 und weiter)

Kontext · 2014 hatte Ubers Fahrtvolumen eine einzelne PostgreSQL-Instanz überwachsen, und die NoSQL-Off-the-Shelf-Optionen der Zeit (Cassandra, Couchbase, MongoDB) hatten operationale Eigenheiten, die Uber für Trip- und Zahlungsdaten nicht akzeptieren wollte. Trip-State braucht stark konsistente Multi-Region-Schreibvorgänge, niedrige p99-Latenz und Zero-Downtime-Sharding. Die Antwort der Branche 2014 war „wählt ein NoSQL und lebt mit den Trade-offs".

Entscheidung · MySQL als dauerhaftes Bedrock behandeln und darauf bauen. Schemaless wickelt sharded MySQL mit einem triggerlosen Append-Only-Log, automatischem Re-Sharding und einer JSON-Document-API ein. Jahre später überlagert Docstore einen stark konsistenten, multi-region transaktionalen Document Store auf demselben MySQL-Substrat — und wird zum Default für neue Produktdaten.

Konsequenzen · Uber blieb außerhalb des Boom-Bust-Zyklus „wir migrieren zu NewSQL"/„wir migrieren zurück zu Postgres", der mehrere Unternehmen ähnlicher Größe traf. Der Pfad ist inkrementell: neue Workloads bekommen Docstore; reife Workloads bleiben auf Schemaless bis zur Migration. Beide werden von einem kleinen Plattform-Team mit tiefer MySQL-Expertise betrieben. Das Gerücht, Uber sei voll auf Cassandra umgestiegen? Sie verwenden Cassandra, aber es war nie das System of Record für Trips.

Dieser ADR ist ein großartiges Beispiel für path-dependent Architektur: 2014 war die richtige Antwort, MySQL zu erweitern, nicht davon weg zu migrieren.

Archyl-Funktion im Einsatz. Drift-Erkennung zählt hier am meisten. Wenn ein neuer Service anfängt, in „Schemaless" zu schreiben, aber das C4-Modell immer noch „PostgreSQL" sagt, berechnet Archyl einen Drift-Score gegen die Codebase und meldet ihn wöchentlich. ADRs verhindern den nächsten Drift: Ein neues Team, das in einen neuen Datastore schreibt, müsste einen ADR einreichen, der die Änderung vorschlägt, den das Plattform-Team genehmigen oder ablehnen kann.

Drei Entscheidungen. Drei Karten in Archyl, jede mit den C4-Elementen verknüpft, die sie formt — H3 mit jedem räumlichen Container, Cadence mit jedem langlebigen Workflow, Schemaless/Docstore mit der Datenebene. Das Diagramm ist die Gegenwart; die ADRs sind das Warum.

Ownership: ein Modell in Verantwortung verwandeln

Ein C4-Modell ist ein statisches Artefakt, bis Sie Teams darauf abbilden. Uber kommuniziert öffentlich über seine Engineering-Struktur: starke Foundation-Gruppen (Storage, Compute, Networking, Observability, Security, ML Platform, Maps), Produkt-Orgs ausgerichtet auf Mobility, Delivery und Freight, und eine zentrale Marketplace-Organisation, die die produktübergreifende Wirtschafts-Engine besitzt.

Diese aufs C4-Modell ablegen:

• Marketplace besitzt DISCO, den Dynamic-Pricing-Service, Surge, die ETA-Plattform und die Demand/Supply-Forecaster
• Mobility Engineering besitzt die Fahrgast- und Fahrer-Apps, den Trip-Orchestrator, die Rating- und Tipping-Flows, das Safety-Toolkit
• Delivery Engineering besitzt Eats's Order-Orchestrierung, Courier-Matching (das DISCO-Primitives wiederverwendet), Händler-Tools und die Menü/Inventar-Plattformen
• Freight Engineering besitzt die langstreckenspezifischen Workflows: Load-Matching, Broker-Tools, Settlement
• Maps besitzt Routing, ETA-Modelle, Verkehrs-Ingestion, die H3-Bibliothek
• ML Platform (Michelangelo) besitzt Modelltraining, Feature Stores, Online-Serving und den ML-Observability-Stack
• Storage Platform besitzt Schemaless, Docstore, Cassandra, das Backup/Restore-Tooling
• Compute Platform besitzt den Cluster-Manager der Kubernetes-Ära und die Nachfahren von Aurora/Peloton
• Observability besitzt M3 (Metrics), Jaeger (Tracing), die Log-Pipeline
• Security & Identity besitzt Risk, IAM, die Secrets-Plattform und die mit Marketplace geteilten Abuse/Fraud-Signale
• Cadence/Workflow Platform besitzt das durable Workflow-Runtime, das von jedem Produkt verwendet wird

Sobald ein System, Container oder Komponente einen Team-Owner hat, wird Drift-Erkennung verantwortlich. Wenn ein neuer Service in Commits auftaucht und nicht im Diagramm ist, wird ein bestimmtes Team gefragt. Wenn eine Konformitätsregel verletzt wird — „nur Marketplace-Services dürfen in den Surge-Cache schreiben" — gibt es einen Namen in einem Posteingang.

In Archyl ist die Ownership Map der Moment, in dem ein Dokumentationstool zu einem Governance-Tool wird.

Archyl-Funktion im Einsatz. Jedes C4-Element unterstützt owners.teams und owners.users. Die Ownership Map-Ansicht rollt Coverage zusammen, sodass Sie die Boxen sehen (und beheben), die niemand besitzt. Coverage-Lücken sind in jedem System dieser Größe inakzeptabel — so eskaliert Bereitschaft zu einem Slack-Kanal, in dem niemand antwortet.

Drift, Konformität und das Viertausend-Service-Problem

Ein Modell mit viertausend Microservices wird driften. Hart. Mobility shipped ein Feature; ein neuer Microservice taucht auf; der Marketplace-Datenvertrag entwickelt sich; ein 2019 deprecated Service wird endlich abgeschaltet. Multiplizieren Sie das mit jedem Team, jedem Quartal.

Archyl berechnet wöchentlich einen Drift-Score: die Lücke zwischen dem dokumentierten C4-Modell und dem, was derzeit in der Codebase ist. Die Zahl ist zwischen 0 und 100 begrenzt. Ein Drift-Score von 12 könnte sechs neue Services bedeuten, die noch nicht im Modell sind, drei Beziehungen im Diagramm, die auf gelöschte Endpoints zeigen, und eine Handvoll Container, die mit Technologien getaggt sind, die nicht mehr dem tatsächlichen Stack entsprechen.

Konformitätsregeln fügen die Policy-Schicht hinzu. Beispiele, die eine Marketplace-Org schreiben könnte:

• Nur Marketplace-Services können aus dem Surge-Cache lesen
• Jeder Container, der PII verarbeitet, muss das Tag pii:true tragen und einen Identity-ADR referenzieren
• Alle öffentlichen APIs müssen einen angehängten OpenAPI- oder gRPC-Vertrag haben — und dieser Vertrag muss die Source of Truth sein, nicht die Implementierung
• Jeder Container braucht ein Owner-Team
• Trip-Zustandsmutationen müssen durch Cadence gehen; direkte Datenbankschreibvorgänge sind verboten
• Neue Datastores erfordern einen ADR und ein Storage-Platform-Sign-off

Archyl bewertet diese Regeln kontinuierlich. Verstöße werden auf dem Diagramm, im wöchentlichen Digest des Teams und als Commit-Time-Checks angezeigt, wenn Sie die GitHub Action verdrahten.

Archyl-Funktionen im Einsatz.

• Drift-Score für die Lücke zwischen Modell und Code, neu berechnet bei jedem Push
• Konformitätsregeln als YAML autoriert, auf alle C4-Elemente angewendet
• Architecture Change Requests — Pull-Request-stilige Review für vorgeschlagene Modellanderungen, sodass die Architektur dieselbe Strenge wie der Code befolgt
• Architecture Insights — KI-aufgetauchte Anomalien und Empfehlungen aus den Drift- + Konformitätssignalen

Für einen Stack der Größe von Uber ist das nicht optional. Es ist die einzige Möglichkeit, das Modell ehrlich zu halten, ohne ein dediziertes Architektur-Dokumentations-Team.

API-Verträge, Events und das Nervensystem des Marketplace

Der Marketplace bei Uber ist ein Graph von Services, die mit hoher Geschwindigkeit Events austauschen. Trip-State-Übergänge, Fahrer-Standort-Updates, Surge-Neuberechnungen, Fare-Quotes, Zahlungsautorisierungen — jede Änderung emittiert ein Kafka-Event, das von null bis vielen nachgelagerten Services konsumiert wird. Die meisten synchronen Service-zu-Service-Aufrufe sind gRPC.

In Archyl:

• Jeder Container kann einen angehängten API-Vertrag haben (HTTP/OpenAPI, gRPC, GraphQL oder AsyncAPI). Die Spec wird inline gerendert; Consumer sehen genau, was sie aufrufen.
• Jeder asynchrone Kanal kann als Event Channel modelliert werden mit Broker (Kafka), Topic-Name, Schema-Format (Avro, Protobuf, JSON Schema) und dem Schema-Body. Producer und Consumer sind mit dem Kanal verknüpft.
• Breaking Changes erscheinen als Diff auf dem Vertrag — und wenn Sie Konformitätsregeln haben, die einen Versionsbump erfordern, wird die Änderung blockiert, bis die Regel erfüllt ist.

Für Uber sind das dreitausend Topics und zehntausende von Verträgen, die vom selben Ort wie das C4-Modell aus inspizierbar werden. Kein „Wer konsumiert meine Events?" mehr — das Modell weiß es.

DORA in Marketplace-Größenordnung

Sobald Sie C4-Elemente mit Ownern haben, können Sie sie mit Delivery-Telemetrie verbinden. Archyls DORA-Modul zieht Deployment-Frequenz, Lead Time für Änderungen, Change Failure Rate und mittlere Wiederherstellungszeit aus Ihren CI/CD- und Incident-Systemen — und rollt sie nach C4-Element und nach Team zusammen.

Für Mobilitys Trip Orchestrator würden Sie die Deployment-Kadenz und Stabilität dieses Teams getrennt von Pricings sehen. Für Marketplace insgesamt würden Sie sehen, wie sich die MTTR der gesamten Plattform entwickelt. Wenn die MTTR ansteigt, drillen Sie in die fehlerhaften Container; wenn die Deploy-Frequenz stagniert, können Sie sie einem bestimmten Teilbaum zuordnen.

Archyl-Funktion im Einsatz. Das DORA-Dashboard in Archyl rendert die vier Metriken mit Team- und Element-Aufschlüsselungen und Trendlinien und verknüpft Incidents mit den Architektur-Elementen, die sie betroffen haben. So wird aus „wir haben Observability" „wir haben Engineering-Gesundheit".

Und dann ist da noch die KI-Ebene

Ein 4.000-Service-Stack ist der natürliche Lebensraum für KI-Coding-Agenten — Claude Code, Cursor, Windsurf und der Rest. Jeder Uber-Ingenieur hat dasselbe Problem: „Wie spricht Service X mit Service Y, und wo wird der Surge-Multiplikator tatsächlich persistiert?"

In Archyl wird das Modell über einen MCP-Server exponiert. Jeder KI-Agent auf dem Laptop eines Ingenieurs kann fragen:

• „Liste alle Services, die von der H3-Bibliothek abhängen"
• „Zeig mir den API-Vertrag für dispatch.MatchService"
• „Welche ADRs decken Speicher-Entscheidungen ab?"
• „Generiere einen Migrationsplan von Cadence zu Temporal SDK v2 über besessene Services"

Der Agent bekommt denselben architektonischen Kontext wie ein Ingenieur. Onboarding schrumpft. Cross-Team-Code-Reviews hören auf, „was macht das überhaupt?" zu sein. Der Kontext, der in Köpfen lebte, lebt jetzt in einem abfragbaren Modell.

Archyl-Funktionen im Einsatz. MCP-Server für KI-Agenten, Import/Export in archyl YAML, Structurizr DSL, LikeC4, IcePanel JSON und Backstage-Catalog-Format — sodass bestehende Architekturdaten ohne Rewrite einfließen. Projekt-Dokumentation, User Flows und Architecture Insights runden die Oberfläche ab.

Die volle Feature-Oberfläche für eine Organisation dieser Größenordnung

Wenn Sie eine Uber-förmige Engineering-Org sind, die Archyl evaluiert, hier ist die Oberfläche, abgebildet auf die Teile Ihres Alltags, in denen sie ihren Lebensunterhalt verdient:

• C4-Modell mit allen vier Ebenen — Systemkontext, Container, Komponente, Code — mit Auto-Layout, Overlays und Click-Through-Navigation. Das, was jedes Diagramming-Tool richtig macht; wir machen es richtig und gehen weiter.
• KI-Architektur-Discovery — zeigen Sie Archyl auf ein Repository, und es entdeckt C4-Elemente automatisch. Bringt Sie in einer Stunde von null zum ersten Modell, nicht in einem Quartal.
• Architecture-as-Code — archyl.yaml in Git eingecheckt, geparst und validiert. CI/CD-bereit über GitHub Action. Dieselbe Strenge wie Code.
• Multi-Format-Import — Backstage-Katalog (JSON), Structurizr DSL, LikeC4, IcePanel JSON, plus Archyls natives YAML.
• ADRs verknüpft mit C4-Elementen mit vollem Lebenszyklus (proposed / accepted / deprecated / superseded).
• Projekt-Dokumentation mit Markdown, Anhängen, Verknüpfung mit spezifischen Elementen — Ihr lebendes Architektur-Handbuch.
• API-Verträge für HTTP/gRPC/GraphQL/AsyncAPI, inline gegen den produzierenden Container gerendert.
• Event Channels mit Broker, Topic, Schema, Producern und Consumern — die asynchrone Seite der Architektur.
• Releases & Umgebungen — versionierte Deployments an die Architektur gebunden, auf dem Diagramm angezeigt.
• Ownership Map mit Team- und Benutzerzuweisungen auf jeder Ebene.
• Drift-Score zwischen dem Modell und der tatsächlichen Codebase, neu berechnet bei jedem Push.
• Konformitätsregeln als Policy auf dem Modell — autorieren, evaluieren und durchsetzen.
• Architecture Change Requests — Pull-Request-stilige Review für vorgeschlagene Modellanderungen.
• Architecture Insights — KI-aufgetauchte Anomalien, Risiken und Empfehlungen.
• DORA-Metriken zusammengerollt nach Element und Team, mit Trendlinien und Incident-Zuordnung.
• Architecture Team Digest — eine wöchentliche teamweise Zusammenfassung, die auf das besessene Perimeter des Teams beschränkt ist.
• MCP-Integration — jeder KI-Coding-Agent im Team teilt denselben architektonischen Kontext.
• GitHub-PR-Reviews — Archyls Review-Bot kommentiert architektur-beeinflussende PRs mit Drift-, Konformitäts- und ADR-Kontext.
• Sharing & Embedding — öffentliche Links, team-only Links, einbettbare iFrames für interne Wikis.
• Bild/PDF-Export — PNG, SVG und PDF für Präsentationen, formelle Docs und gedruckte Folien.
• Mehrsprachig — jede Archyl-Oberfläche in neun Sprachen verfügbar, einschließlich der Docs und der Agent-Prompts.

Das ist der volle Werkzeugkasten. Für einen Stack wie Ubers würden Sie ungefähr alles davon nutzen. Für einen Stack mit fünfzig Services würden Sie die Hälfte nutzen, die zu Ihrer Reife passt — und in den Rest hineinwachsen.

Sie brauchen keine viertausend Services

Sie sind nicht Uber. Die meisten Engineering-Organisationen sind es nicht.

Aber die Lektion skaliert nach unten. Die Disziplin, Kontext von Container von Komponente zu trennen, den ADR zu schreiben, der eine path-dependent Entscheidung erklärt (wir haben H3 gebaut, wir haben Cadence gebaut, wir haben MySQL erweitert statt es zu ersetzen), Ownership an jede Box anzuhängen — diese Disziplin ist es, die einen Fünfzig-Service-Stack davor bewahrt, sich wie viertausend anzufühlen.

C4 + ADRs + Ownership + Drift + Konformität + API-Verträge + DORA + MCP — das ist es, was Archyl Ihnen out of the box gibt. Das Uber-Beispiel ist nur der größte plausible Stresstest des Modells im Marketplace-und-Logistik-Bereich.

Öffnen Sie Ihre eigene Architektur. Skizzieren Sie zehn Produkte (oder drei, wenn Sie drei haben). Picken Sie das mit den überraschendsten Vergangenheitsentscheidungen heraus und zoomen Sie in seine Container. Schreiben Sie drei ADRs, die erklären, was einen Neuankömmling verwirren würde. Mappen Sie ein Team auf jeden Container.

Sie werden vor dem sein, wo die meisten Engineering-Organisationen in einem Jahr ankommen.

Möchten Sie Ihre eigene Architektur in C4 modellieren? Mit Archyl starten. Mehr darüber lesen, warum ADRs und C4 zusammen besser funktionieren oder wie Architecture Change Requests Pull-Request-Strenge in Ihr C4-Modell bringen. Die vorherigen Fallstudien modellierten Stripe in C4 — Anatomie einer Charge und Netflix in C4 — Anatomie eines Plays.