Disclaimer. Questo articolo si basa interamente sulle comunicazioni pubbliche di Uber — il loro engineering blog, talk di conferenze, repository open source e case study esterni. Non è un documento di architettura ufficiale di Uber. Modelliamo ciò che sappiamo pubblicamente per illustrare come uno stack di quattromila servizi possa essere reso leggibile con il modello C4. Dove i dettagli sono inferiti piuttosto che dichiarati da Uber, lo diciamo.

Anatomia di una corsa: modellare Uber in C4 con Archyl

Un passeggero tocca Richiedi UberX alle 19:23 in un venerdì piovoso a Manhattan. Otto secondi dopo, un autista a 0,4 miglia ha accettato la corsa, è stato calcolato e renderizzato un ETA, la tariffa è bloccata, il pagamento è preautorizzato e un canale in tempo reale a bassa latenza è aperto tra passeggero e autista. Quando alza gli occhi dal telefono, l'auto sta già andando verso di lui.

Quel singolo tap, ripetuto più di 30 milioni di volte al giorno in 600+ città, attraversa decine di sistemi Uber e tre reti esterne prima che il frame zero atterri sullo schermo dell'autista.

Nel 2024, lo stack di Uber faceva girare circa 4.000 microservizi, serviva picchi di ben oltre un milione di richieste al secondo ai suoi client mobile, schedulava compute sul proprio cluster manager, persisteva stato nel proprio storage layer derivato da MySQL, indicizzava il pianeta sulla propria griglia esagonale, orchestrava milioni di workflow di corse sul proprio motore di state machine e addestrava modelli ETA sulla propria piattaforma ML.

Come si capisce uno stack con così tante parti in movimento? Come Stripe e Netflix, non si capisce — non tutto in una volta. È esattamente il problema che il modello C4 è stato inventato per risolvere.

In questo post seguiamo una singola azione utente — una richiesta di corsa dal tap all'accettazione dell'autista — e la guardiamo attraversare l'architettura di Uber attraverso i quattro livelli C4. Non copriremo ogni prodotto; tracceremo una corsa, scriveremo gli ADR che spiegano le scelte incontrate lungo la strada, e finiremo con una mappa dei team che possiedono ogni box. Lungo il percorso, faremo un tour di ogni funzionalità che Archyl offre per rendere questo tipo di modello — e le policy attorno — effettivamente manutenibile.

Livello 1 — System Context: tre piattaforme, un Marketplace

A System Context, Uber non è "un'app di ride-hailing". È tre piattaforme prodotto sedute sopra un Marketplace condiviso e uno stack di sistemi Foundation trasversali:

1. Mobility — UberX, Uber Black, Uber Pool, Uber Reserve, Comfort, SUV, Premier, partnership con taxi
2. Delivery — Uber Eats (cibo), Uber Direct (delivery-as-a-service di terze parti), Postmates, alcol, spesa
3. Freight — trasporto a lunga distanza, Uber Freight Loadbuilder, strumenti broker

Sotto di loro, la piattaforma Marketplace è il cervello vero — il motore di matching, l'ottimizzatore di dispatch, il sistema di pricing dinamico, i forecaster di domanda/offerta. Marketplace è ciò che trasforma una richiesta di corsa in una corsa.

Sotto siedono le piattaforme Foundation: Maps (routing, ETA, matrici di distanza/durata, traffico), Payments, Identity & Risk, Communications (push, SMS, messaggistica in-app), Notifications, la piattaforma ML (Michelangelo), il motore Workflow (Cadence/Temporal), le piattaforme Storage (Schemaless, Docstore, Cassandra, store basati su RocksDB), le piattaforme Streaming (Kafka, uReplicator, Flink), lo stack di Observability (M3 metrics, Jaeger tracing, ELK logs) e la piattaforma Compute (storicamente Mesos + Aurora → Peloton → oggi Kubernetes-based).

Attorno a loro, gli attori esterni: passeggeri, autisti, eaters, corrieri, mercanti, shipper e carrier, fornitori di mappe (i loro + terze parti come fallback), reti di pagamento e banche acquirenti, fornitori di verifica identità, operatori telecom per SMS e voce, fornitori cloud (Uber gira ibrido: data center propri + AWS/GCP per workload specifici) e regolatori a livello cittadino.

Tre piattaforme prodotto. Un Marketplace. Dieci piattaforme Foundation. Tutto il resto è dettaglio.

Questo è il regalo del Livello 1: a System Context, non hai bisogno di sapere che Mobility sono duecento microservizi. Hai bisogno di sapere che esiste, che parla con Marketplace, che Marketplace parla con Maps, e che Cadence orchestra il workflow di corsa lungo sotto. Il diagramma è uno spunto di conversazione, non un inventario.

Funzionalità Archyl in gioco. Un diagramma System Context in Archyl è una singola vista C4 Livello 1 con auto-layout, navigazione click-through nei container e overlay che ti permettono di silenziare/evidenziare sottoinsiemi (es. "mostra solo le piattaforme Foundation"). Gli attori esterni sono elementi C4 di prima classe con il proprio tipo, quindi vengono renderizzati in modo distinto.

ADR-001 · Griglia esagonale H3 per indicizzazione geospaziale

Stato · Accettato (2018, open-sourced; ancora attivo nel 2026)

Contesto · Il motore di matching di Marketplace deve rispondere "quali autisti sono vicini a questo passeggero?" in millisecondi, a concorrenza city-wide, supportando al contempo analytics come zone surge, ETA e supply forecasting. Le opzioni classiche erano tilings rettangolari (Z-order, geohash, celle S2 di Google) ma i rettangoli hanno un difetto fondamentale per questo dominio: ogni rettangolo ha più di una distanza-vicino — gli angoli sono più lontani dei bordi, il che produce approssimazioni di distanza disuguali e query "cosa c'è vicino" asimmetriche.

Decisione · Tilare il pianeta in esagoni invece. Costruire una griglia esagonale gerarchica (H3) con sedici risoluzioni dalla scala continentale fino a ~1 m². Ogni esagono ha sei vicini equidistanti, rendendo le query nearest-neighbor e ring simmetriche e veloci. Open-sourcare la libreria così che partner e ingegneri Uber condividano la stessa griglia.

Conseguenze · H3 è diventato il primitivo spaziale di Uber attraverso Marketplace, Maps, ETA, surge e analytics. Lo stesso H3Index è usato negli hot path di dispatch e nei job offline di forecasting. È anche uno dei progetti open source di maggior successo di Uber — usato da Foursquare, DoorDash, AT&T e innumerevoli geo-startup. I pochi casi in cui gli esagoni non si tilano puliti (le 12 ancore pentagonali dell'icosaedro) sono documentati ed evitati nel codice di produzione.

In Archyl, è così che un ADR si guadagna il suo posto: spiega perché il confine ha quella forma. Clicca su qualsiasi container che tocca stato geospaziale e l'ADR H3 è a un click.

Funzionalità Archyl in gioco. Gli ADR in Archyl sono record di prima classe collegati a specifici elementi C4. Appaiono come card sui box rilevanti, sono filtrabili per stato (proposed, accepted, deprecated, superseded) e vengono spediti su git come YAML così vivono accanto al codice. Quando qualcuno proporrà di rimpiazzare H3 nel 2030, l'ADR esistente apparirà automaticamente come contesto correlato.

Livello 2 — Container: zoom nel percorso di dispatch del Marketplace

Il tap del passeggero atterra all'edge dell'API. Apriamo la scatola.

Il percorso di dispatch attraversa qualcosa come i seguenti container:

• Edge gateway — storicamente TChannel + Thrift IDL, oggi un edge gRPC + HTTP/2 per i client mobile. Fa auth, rate limiting, request shaping e routing.
• Trip orchestrator — gira come un workflow Cadence/Temporal di lunga durata. La corsa è un'istanza di workflow con transizioni di stato deterministiche: requested → matched → arriving → on-trip → completed. Retry idempotenti ed escalation timer-driven sono primitive built-in, non codice bespoke.
• Motore di matching (DISCO) — l'ottimizzatore marketplace vero. Data una richiesta passeggero e l'offerta autisti live entro qualche distanza-ring H3, risolve un problema di assegnazione vincolato a ogni tick.
• Servizio pricing dinamico — combina segnali real-time supply/demand per calcolare moltiplicatori surge per cella H3. Restituisce un quote tariffa che viene bloccato al momento della richiesta.
• Servizio ETA — alimenta Maps + modelli ML per route, traffico e predizione di arrivo. I modelli ETA di Uber sono passati al deep learning intorno al 2018 e sono stati raffinati ogni anno da allora.
• Piattaforma Maps — motore di routing in-house di Uber, servizio distance-matrix e pipeline di ingestion del traffico. Fa fallback su provider di mappe esterni in mercati selezionati.
• Servizio Driver state — traccia lo stato corrente di ogni autista (offline, online, in corsa), localizzazione e comportamento di accettazione. Read/write su dati location hot-path tramite geo-store custom.
• Schemaless / Docstore — storage MySQL sharded di Uber. Schemaless è il vecchio; Docstore è il successore più nuovo, multi-region, transazionale. Stato corsa, pagamenti, profili utente e la maggior parte dei dati line-of-business vivono qui.
• Cluster Kafka — ogni transizione di stato emette un evento. Marketplace si sottoscrive per analytics; i servizi downstream si sottoscrivono per fanout (notifications, frodi, contabilità).
• Canale real-time — una volta matchato, un canale bidirezionale a bassa latenza tra le app passeggero e autista per location updates e chat. Supportato da gateway long-poll/WebSocket e Kafka sotto.

Il tech stack a questo livello: Go per la maggior parte dei nuovi servizi ad alto throughput, Java nel codice marketplace più vecchio, Python nelle pipeline ML e script ops, Node.js in alcuni layer edge, gRPC come protocollo RPC moderno (TChannel/Thrift era il predecessore), Cassandra e Redis per latenza hot-path, MySQL sotto Schemaless/Docstore, Hadoop/HDFS/Hive/Presto per il data warehouse, Spark/Flink per compute batch e streaming.

Una richiesta corsa tipica tocca Edge gateway → Trip orchestrator (Cadence) → Motore di matching (DISCO con query ring H3 contro Driver state) → Pricing dinamico → ETA → fanout Notifications (push all'autista) → callback driver-accept → canale real-time stabilito. Tutto questo, con retry, strumentato end-to-end via Jaeger e misurato via M3.

Funzionalità Archyl in gioco. I diagrammi a livello Container mostrano ogni container, il suo tipo (api / service / database / message_queue / cache / worker / gateway / library / infrastructure), le sue tecnologie (estratte da un catalogo tecnologico per organizzazione) e le sue relazioni con etichette. I contratti API possono essere allegati a qualsiasi container e renderizzati inline — Uber linkerebbe il .proto gRPC per l'orchestrazione corsa direttamente al container Trip orchestrator.

ADR-002 · Cadence (Temporal) — costruisci un motore di workflow, non accatastare microservizi stateful

Stato · Accettato (~2017, open-sourced come Cadence; spinout come Temporal)

Contesto · Verso il 2017, Uber aveva centinaia di microservizi che implementavano processi business stateful di lunga durata — corse, ordini, flow di signup, onboarding autisti, review frodi. Ognuno aveva fatto crescere la propria state machine ad-hoc con timer, retry, idempotenza e codice di recovery. Risultato: ogni team pagava la tassa dei distributed system, e gli outage venivano frequentemente da bug sottili nella logica retry/timeout.

Decisione · Non chiedere a ogni team di inventare una state machine. Costruire un motore di workflow generico con replay deterministico, timer durabili, retry automatici, gestione signal e un modello di programmazione dove il codice workflow si legge come logica business sequenziale. Open-sourcarlo come Cadence. Migrare corse, signup, review frodi e workflow di movimento denaro su di esso nel corso di diversi anni.

Conseguenze · Cadence (e il suo fork Temporal, ora usato dentro e fuori Uber) è ora il substrato per ogni flow stateful di lunga durata in Uber. L'astrazione "la corsa è un workflow" collassa migliaia di righe di codice retry bespoke in una manciata di activity ben tipate. Il motore è anche diventato uno dei progetti workflow open source più adottati nell'industria. La lezione path-dependent: quando dieci team stanno reimplementando indipendentemente la stessa primitiva, costruisci la primitiva.

Funzionalità Archyl in gioco. Le decisioni come Cadence si propagano nel modello. In Archyl, un ADR può collegare più elementi C4 simultaneamente — una decisione, molti box impattati. Cercare "workflow" nel modello fa emergere ogni container annotato come consumer Cadence.

Livello 3 — Componente: dentro il motore di matching

Di tutti i componenti nello stack di Uber, il motore di matching — internamente DISCO — è il più ben documentato in talk di conferenze e post di engineering.

Una singola richiesta corsa, una volta raggiunto il motore di matching, attraversa questi componenti:

1. Request normalizer — converte le coordinate del passeggero in un indice H3 a multiple risoluzioni (tipicamente res 9 per hot-path, res 6 per ring expansion).
2. Supply scanner — interroga l'indice driver-state live per tutti gli autisti idonei entro un ring H3 iniziale (~500 m). Filtra per tipo veicolo, tasso di accettazione autista e comportamento decline recente.
3. Ring expander — se non esistono autisti idonei nel ring interno, espande verso l'esterno in ring H3 concentrici fino a quando si forma un set candidato o si raggiunge un bound max-distance. Uber ha pubblicato diverse iterazioni di questa strategia di expansion, inclusa expansion ML-driven che predice i percorsi probabili degli autisti.
4. Candidate ranker — punteggia ogni candidato su ETA-al-pickup, efficienza marketplace (vogliamo tenere questo autista in questo quartiere?) e probabilità di accettazione storica per questa coppia passeggero/autista.
5. Assignment solver — formula il problema di matching come ottimizzazione vincolata sul pool di offerta locale. Il solver gira continuamente, batchando richieste vicine invece di committarsi a un greedy first-best-match.
6. Notification dispatcher — invia al candidato matchato una push notification con una finestra di accettazione corta. Registra accept/decline indietro in driver-state.
7. Path di fallback — su timeout solver o nessun candidato idoneo, retry con vincoli rilassati (tipi veicolo più ampi, ETA più lungo) o escalation a surge.

Il pattern è brutalmente semplice una volta visto: ogni query spaziale è un ring H3; ogni decisione business è un candidato punteggiato; ogni match è l'output di un solver run globale, non una decisione locale greedy. La forma elimina un'intera classe di anti-pattern "il primo autista afferra la corsa" che affliggono i sistemi dispatch ingenui.

Ecco come si vede C4 a livello Componente: non "ecco del codice", ma "ecco la catena di primitive significative per il business, ognuna posseduta, ognuna sostituibile, ognuna misurabile".

Funzionalità Archyl in gioco. I diagrammi Componente mostrano come è costruito un container. Ogni componente ha un tipo (controller / service / repository / handler / module / job / workflow / activity / entity), un path di file, owner e tecnologie. I componenti si compongono in un User Flow — la funzionalità flow di Archyl ti permette di authorare il viaggio del passeggero come una sequenza ordinata di invocazioni di componenti e renderizzarlo come diagramma step-by-step.

ADR-003 · Schemaless e Docstore — possedi lo storage layer invece di comprare

Stato · Accettato (Schemaless: ~2014; Docstore: ~2020 in poi)

Contesto · Verso il 2014, il volume di corse di Uber aveva superato una singola istanza PostgreSQL, e le opzioni NoSQL off-the-shelf dell'epoca (Cassandra, Couchbase, MongoDB) avevano stranezze operative che Uber non era disposta ad accettare per dati corse e pagamenti. Lo stato corsa ha bisogno di scritture multi-region fortemente consistenti, latenza p99 bassa e sharding zero-downtime. La risposta dell'industria nel 2014 era "scegli un NoSQL e convivi con i trade-off".

Decisione · Trattare MySQL come bedrock durabile e costruire sopra. Schemaless wrappa MySQL sharded con un log append-only triggerless, re-sharding automatico e API documento JSON. Anni dopo, Docstore sovrappone un document store transazionale multi-region fortemente consistente sullo stesso substrato MySQL — e diventa il default per i nuovi dati prodotto.

Conseguenze · Uber è rimasta fuori dal ciclo boom-bust di "migreremo a NewSQL"/"torneremo a Postgres" che ha colpito diverse aziende di dimensione simile. Il path è incrementale: nuovi workload vanno su Docstore; workload maturi rimangono su Schemaless fino alla migrazione. Entrambi sono operati da un piccolo team piattaforma con expertise MySQL profonda. Il rumor che Uber sia andata all-in su Cassandra? Usano Cassandra, ma non è mai stato il system of record per le corse.

Questo ADR è un grande esempio di architettura path-dependent: nel 2014, la risposta giusta era estendere MySQL, non migrare via.

Funzionalità Archyl in gioco. La rilevazione drift conta di più qui. Quando un nuovo servizio inizia a scrivere su "Schemaless" ma il modello C4 dice ancora "PostgreSQL", Archyl calcola un drift score contro la codebase e lo segnala settimanalmente. Gli ADR prevengono il prossimo drift: un nuovo team che scrive su un nuovo datastore dovrebbe registrare un ADR proponendo il cambiamento, che il team piattaforma può approvare o rifiutare.

Tre decisioni. Tre card in Archyl, ognuna collegata agli elementi C4 che plasma — H3 a ogni container spaziale, Cadence a ogni workflow di lunga durata, Schemaless/Docstore al data tier. Il diagramma è il presente; gli ADR sono il perché.

Ownership: trasformare un modello in accountability

Un modello C4 è un artefatto statico fino a quando non vi mappi i team. Uber comunica pubblicamente sulla sua struttura engineering: forti gruppi Foundation (Storage, Compute, Networking, Observability, Security, ML Platform, Maps), org prodotto allineate a Mobility, Delivery e Freight, e un'organizzazione Marketplace centrale che possiede il motore economico cross-prodotto.

Posa questi sul modello C4:

• Marketplace possiede DISCO, il servizio pricing dinamico, surge, la piattaforma ETA e i forecaster demand/supply
• Mobility Engineering possiede le app passeggero e autista, il trip orchestrator, i flow rating e tipping, il toolkit safety
• Delivery Engineering possiede l'orchestrazione ordini di Eats, courier matching (che riusa primitive DISCO), gli strumenti merchant e le piattaforme menu/inventario
• Freight Engineering possiede i workflow specifici long-haul: load matching, strumenti broker, settlement
• Maps possiede routing, modelli ETA, ingestion traffico, la libreria H3
• ML Platform (Michelangelo) possiede il training modelli, feature store, online serving e lo stack di observability ML
• Storage Platform possiede Schemaless, Docstore, Cassandra, il tooling backup/restore
• Compute Platform possiede il cluster manager era Kubernetes e i discendenti di Aurora/Peloton
• Observability possiede M3 (metrics), Jaeger (tracing), la pipeline log
• Security & Identity possiede Risk, IAM, la piattaforma secret e i segnali abuse/frodi condivisi con Marketplace
• Cadence/Workflow Platform possiede il runtime workflow durabile usato da ogni prodotto

Una volta che un sistema, container o componente ha un team owner, la rilevazione drift diventa accountable. Quando un nuovo servizio appare nei commit e non è sul diagramma, un team specifico riceve la domanda. Quando una regola di conformità viene violata — "solo i servizi Marketplace possono scrivere sulla cache surge" — c'è un nome in una inbox.

In Archyl, l'Ownership Map è il momento in cui uno strumento di documentazione diventa uno strumento di governance.

Funzionalità Archyl in gioco. Ogni elemento C4 supporta owners.teams e owners.users. La vista Ownership Map consolida la coverage così vedi (e correggi) i box che nessuno possiede. I gap di coverage sono inaccettabili in qualsiasi sistema di queste dimensioni — è così che on-call escalation arriva a un canale Slack dove nessuno risponde.

Drift, conformità e il problema dei quattromila servizi

Un modello con quattromila microservizi farà drift. Forte. Mobility ship una feature; appare un nuovo microservizio; il contratto dati del Marketplace evolve; un servizio deprecated del 2019 viene finalmente ritirato. Moltiplica per ogni team, ogni trimestre.

Archyl calcola un drift score settimanalmente: il gap tra il modello C4 documentato e ciò che è attualmente nella codebase. Il numero è limitato tra 0 e 100. Un drift score di 12 potrebbe significare sei nuovi servizi non ancora nel modello, tre relazioni nel diagramma che puntano a endpoint cancellati, e una manciata di container taggati con tecnologie che non corrispondono più allo stack reale.

Le regole di conformità aggiungono il policy layer. Esempi che un'org Marketplace potrebbe scrivere:

• Solo i servizi Marketplace possono leggere dalla cache surge
• Ogni container che gestisce PII deve portare il tag pii:true e referenziare un ADR Identity
• Tutte le API pubbliche devono avere un contratto OpenAPI o gRPC allegato — e quel contratto deve essere la source of truth, non l'implementazione
• Ogni container ha bisogno di un team owner
• Le mutazioni dello stato corsa devono passare per Cadence; le scritture dirette al database sono proibite
• I nuovi datastore richiedono un ADR e un sign-off Storage Platform

Archyl valuta queste regole continuamente. Le violazioni emergono sul diagramma, nel digest settimanale del team e come check al commit-time se cabli la GitHub Action.

Funzionalità Archyl in gioco.

• Drift score per il gap tra modello e codice, ricalcolato a ogni push
• Regole di conformità authorate come YAML, applicate a tutti gli elementi C4
• Architecture Change Requests — review stile pull-request per cambi modello proposti, così l'architettura segue lo stesso rigore del codice
• Architecture Insights — anomalie e raccomandazioni emerse dall'IA dai segnali drift + conformità

Per uno stack delle dimensioni di Uber, questo non è opzionale. È l'unico modo in cui il modello rimane onesto senza un team dedicato alla documentazione architetturale.

Contratti API, eventi e il sistema nervoso del marketplace

Il Marketplace di Uber è un grafo di servizi che si scambiano eventi ad alta velocità. Transizioni stato corsa, aggiornamenti location autista, ricalcoli surge, quote tariffa, autorizzazioni pagamento — ogni cambio emette un evento Kafka consumato da zero-a-molti servizi downstream. La maggior parte delle chiamate sincrone servizio-a-servizio sono gRPC.

In Archyl:

• Ogni container può avere un contratto API allegato (HTTP/OpenAPI, gRPC, GraphQL o AsyncAPI). La spec viene renderizzata inline; i consumer vedono esattamente cosa stanno chiamando.
• Ogni canale async può essere modellato come un Event Channel con broker (Kafka), nome topic, formato schema (Avro, Protobuf, JSON Schema) e il body dello schema. Producer e consumer sono linkati al canale.
• I cambi breaking emergono come un diff sul contratto — e se hai regole di conformità che richiedono un version bump, il cambio è bloccato fino a quando la regola non è soddisfatta.

Per Uber, sono tremila topic e decine di migliaia di contratti che diventano ispezionabili dallo stesso posto del modello C4. Niente più "chi consuma i miei eventi?" — il modello sa.

DORA alla scala Marketplace

Una volta che hai elementi C4 con owner, puoi connetterli alla telemetria di delivery. Il modulo DORA di Archyl tira deployment frequency, lead time per i cambi, change failure rate e mean time to recovery dai tuoi sistemi CI/CD e incident — e li consolida per elemento C4 e per team.

Per il Trip Orchestrator di Mobility, vedresti la cadenza di deployment e la stabilità di quel team separatamente da Pricing. Per Marketplace nel complesso, vedresti come il MTTR dell'intera piattaforma sta tendendo. Quando il MTTR pinna, drilla nei container colpevoli; quando la deploy frequency stalla, puoi attribuirla a un sottoalbero specifico.

Funzionalità Archyl in gioco. La dashboard DORA in Archyl renderizza le quattro metriche con breakdown team e elemento e linee di trend, e lega gli incident agli elementi architetturali che hanno impattato. È come "abbiamo observability" diventa "abbiamo salute engineering".

E poi c'è il livello AI

Uno stack di 4.000 servizi è l'habitat naturale per gli agenti AI di coding — Claude Code, Cursor, Windsurf e il resto. Ogni ingegnere Uber ha lo stesso problema: "come parla il servizio X al servizio Y, e dove viene effettivamente persistito il moltiplicatore surge?"

In Archyl, il modello è esposto via un server MCP. Qualsiasi agente AI sul laptop di un ingegnere può chiedere:

• "Lista tutti i servizi che dipendono dalla libreria H3"
• "Mostrami il contratto API per dispatch.MatchService"
• "Quali ADR coprono le decisioni di storage?"
• "Genera un piano di migrazione da Cadence a Temporal SDK v2 sui servizi posseduti"

L'agente ottiene lo stesso contesto architetturale di un ingegnere. L'onboarding si riduce. Le code review cross-team smettono di essere "cosa fa questa cosa?". Il contesto che viveva nelle teste ora vive in un modello interrogabile.

Funzionalità Archyl in gioco. Server MCP per agenti AI, import/export in YAML archyl, Structurizr DSL, LikeC4, IcePanel JSON e formato catalogo Backstage — così i dati architetturali esistenti fluiscono senza un rewrite. Documentazione progetto, user flow e architecture insights completano la superficie.

La superficie completa di funzionalità per un'organizzazione a questa scala

Se sei un'org engineering forma-Uber che valuta Archyl, ecco la superficie, mappata alle parti del tuo quotidiano dove guadagna il suo posto:

• Modello C4 con tutti e quattro i livelli — System Context, Container, Componente, Code — con auto-layout, overlay e navigazione click-through. La cosa che ogni strumento di diagramming fa bene; noi la facciamo bene e andiamo oltre.
• AI architecture discovery — punta Archyl a un repository e scopre elementi C4 automaticamente. Ti porta da zero al primo modello in un'ora, non un trimestre.
• Architecture-as-Code — archyl.yaml checkato in git, parsato e validato. CI/CD-ready via GitHub Action. Stesso rigore del codice.
• Import multi-formato — catalogo Backstage (JSON), Structurizr DSL, LikeC4, IcePanel JSON, più YAML nativo di Archyl.
• ADR collegati a elementi C4 con ciclo di vita completo (proposed / accepted / deprecated / superseded).
• Documentazione progetto con markdown, attachment, linking a elementi specifici — il tuo handbook architetturale vivente.
• Contratti API per HTTP/gRPC/GraphQL/AsyncAPI, renderizzati inline contro il container produttore.
• Event channel con broker, topic, schema, producer e consumer — il lato async dell'architettura.
• Release & ambienti — deployment versionati legati all'architettura, mostrati sul diagramma.
• Ownership Map con assegnazioni team e utente a ogni livello.
• Drift score tra modello e codebase reale, ricalcolato a ogni push.
• Regole di conformità come policy sul modello — author, valuta e applica.
• Architecture Change Requests — review stile pull-request per cambi modello proposti.
• Architecture Insights — anomalie, rischi e raccomandazioni emerse dall'AI.
• Metriche DORA consolidate per elemento e team, con linee di trend e attribuzione incident.
• Architecture Team Digest — un riepilogo settimanale per team scoped al perimetro posseduto del team.
• Integrazione MCP — ogni agente AI di coding nel team condivide lo stesso contesto architetturale.
• Review PR GitHub — il bot review di Archyl commenta i PR che impattano l'architettura con contesto drift, conformità e ADR.
• Sharing & embedding — link pubblici, link team-only, iframe embeddabili per wiki interni.
• Export immagine/PDF — PNG, SVG e PDF per presentazioni, doc formali e slide stampate.
• Multi-lingua — ogni superficie Archyl disponibile in nove lingue, inclusi i doc e i prompt agente.

Quella è la cassetta degli attrezzi completa. Per uno stack come Uber, useresti pressoché tutto. Per uno stack di cinquanta servizi, useresti la metà che combacia con la tua maturità — e cresceresti nel resto.

Non hai bisogno di quattromila servizi

Non sei Uber. La maggior parte delle organizzazioni engineering non lo è.

Ma la lezione scala in basso. La disciplina di separare Context da Container da Componente, di scrivere l'ADR che spiega una decisione path-dependent (abbiamo costruito H3, abbiamo costruito Cadence, abbiamo esteso MySQL invece di rimpiazzarlo), di attaccare ownership a ogni box — quella disciplina è ciò che impedisce a uno stack di cinquanta servizi di sembrare quattromila.

C4 + ADR + Ownership + Drift + Conformità + Contratti API + DORA + MCP — questo è ciò che Archyl ti dà out of the box. L'esempio Uber è solo lo stress-test plausibile più grande del modello nel dominio marketplace-e-logistica.

Apri la tua architettura. Schizza dieci prodotti (o tre, se ne hai tre). Scegli quello con le decisioni passate più sorprendenti e zooma nei suoi container. Scrivi tre ADR che spiegano cosa confonderebbe un nuovo arrivato. Mappa un team a ogni container.

Sarai avanti rispetto a dove la maggior parte delle organizzazioni engineering arriva in un anno.

Vuoi modellare la tua architettura in C4? Inizia con Archyl. Leggi di più su perché ADR e C4 funzionano meglio insieme o come le Architecture Change Requests portano il rigore della pull-request al tuo modello C4. I case study precedenti hanno modellato Stripe in C4 — Anatomia di una Charge e Netflix in C4 — Anatomia di un Play.