Esempi di modello C4: Stripe, Netflix, Uber e Revolut

La maggior parte degli esempi di modello C4 che si trovano in giro riguarda un unico sistema giocattolo: una banca, un e-commerce, un'app di internet banking con tre box e un database. Mostrano la notazione. Non mostrano la parte difficile, cioè decidere cosa lasciare fuori quando il sistema reale ha centinaia di servizi.

Questa pagina raccoglie quattro esempi di modello C4 più grandi, ognuno modellato dal contesto fino ai componenti: un addebito con carta su Stripe, una richiesta di riproduzione su Netflix, una richiesta di corsa su Uber e un bonifico internazionale su Revolut. Ciascuno è accompagnato dal suo diagramma di livello 1, da un breve riepilogo di come si scende ai livelli 2 e 3 e da un link all'analisi completa. Alla fine trovi un piccolo esempio da copiare e un elenco di ciò che i quattro hanno in comune.

Una nota sulle fonti. Tutti e quattro gli esempi provengono dalla nostra serie "Anatomia di", e ognuno si basa interamente sulle comunicazioni pubbliche dell'azienda: blog di ingegneria, talk a conferenze, repository open source, offerte di lavoro e case study esterni. Nessuno di essi è un documento di architettura ufficiale dell'azienda interessata. Ogni post completo indica dove i dettagli sono dedotti anziché dichiarati dall'azienda.

Se il modello C4 è una novità per te, leggi prima cos'è il modello C4. Le quattro guide per livello approfondiscono ogni tipo di diagramma: contesto di sistema, container, componenti e codice.

Cosa rende buono un esempio C4

Un esempio di diagramma C4 è utile quando ne puoi ricavare una decisione, non solo una forma. I quattro qui sotto sono stati scritti seguendo le stesse regole, e vale la pena rubarle prima ancora di guardarne uno.

Segui una sola azione dell'utente. Nessuno di questi esempi cerca di documentare l'intera azienda. Ognuno sceglie una sola cosa che l'utente fa (un addebito, una riproduzione, una corsa, un bonifico) e disegna solo ciò che quell'azione tocca. È questo che riduce un parco di mille servizi a una pagina leggibile.

Tieni il livello 1 intorno ai dieci box. Al livello System Context, un'azienda come Netflix non è mille microservizi. È una manciata di sistemi di prodotto e gli attori esterni che li circondano. Se il tuo diagramma di livello 1 ha bisogno di quaranta box, i confini sono tracciati all'altezza sbagliata.

Al livello 2, zooma su un solo percorso. Il diagramma dei container mostra i container sul percorso di quell'unica azione, con tecnologie e protocolli. Non mostra ogni container che l'azienda esegue.

Scegli lo zoom di livello 3 per un motivo. Un solo container riceve un diagramma dei componenti, ed è quello dove vive l'ingegneria interessante, oppure quello che l'azienda ha documentato pubblicamente con abbastanza profondità da poterlo modellare onestamente.

Spiega i box con le decisioni. Ogni esempio include tre brevi architecture decision record tra un livello e l'altro. Un diagramma mostra cosa esiste. L'ADR dice perché ha quell'aspetto, che è la prima domanda che si fa un nuovo assunto.

Ecco come si confrontano i quattro a colpo d'occhio:

Esempio 1: Stripe, un addebito con carta

Basato sulle comunicazioni pubbliche di Stripe. Non è un documento di architettura ufficiale di Stripe.

Livello 1. Al livello System Context, Stripe non è "un'API di pagamento". Il nostro modello mostra quindici sistemi di prodotto che condividono un'unica base: Payments, Connect, Billing, Radar, Issuing, Treasury e gli altri. Intorno a loro ci sono i merchant, i titolari di carta, i circuiti delle carte, i metodi di pagamento alternativi, le banche acquirer e issuer, i partner bancari e AWS.

Livello 2. Il diagramma dei container apre il box Payments e segue una sola chiamata PaymentIntents.create(): l'API gateway, un livello di idempotenza davanti a ogni endpoint che modifica lo stato, la macchina a stati del PaymentIntent, un vault per i dati delle carte, lo scoring di Radar in parallelo, i connettori verso i circuiti, il ledger e la consegna dei webhook.

Livello 3. Lo zoom sui componenti entra nel livello di idempotenza, perché è la parte dello stack documentata più pubblicamente: un hasher delle richieste, un key store in PostgreSQL, un esecutore di fasi e un tracker dei punti di ripristino che permette a una richiesta ritentata di riprendere da dove si era fermata.

Cosa portarsi a casa. Questo è l'esempio da studiare per i diagrammi dei componenti. La vista di livello 3 non è un elenco di classi; è una catena di passaggi su cui un lettore può ragionare ("ogni effetto collaterale esterno sta tra due punti di ripristino").

Post completo: Anatomia di un Charge: modellare Stripe in C4.

Esempio 2: Netflix, una richiesta di riproduzione

Basato sulle comunicazioni pubbliche di Netflix. Non è un documento di architettura ufficiale di Netflix.

Livello 1. Dal materiale pubblico di Netflix emergono con costanza dieci sistemi: Member Experience, Content Discovery, Streaming Platform, Open Connect, Studio Engineering, Content Engineering, Data Platform, Cloud Platform, Security e l'Ads Platform. Tra gli attori esterni ci sono i dispositivi degli abbonati, gli ISP che ospitano le appliance Open Connect, AWS, i fornitori di DRM, i partner di pagamento e gli studi che producono i contenuti.

Livello 2. Lo zoom sui container apre la Streaming Platform e segue una richiesta di riproduzione: la Playback API, il servizio dei manifest, il servizio delle licenze per il DRM, il livello di sicurezza dei messaggi, un tier EVCache e i cluster Cassandra che stanno dietro. Il manifest indirizza il dispositivo verso un'appliance Open Connect, ed è lì che ricompare la decisione di livello 1 di costruire una CDN.

Livello 3. La vista dei componenti entra in Cosmos, la pipeline di codifica video. Non si trova sul percorso di riproduzione al momento della richiesta (la codifica avviene quando un titolo viene acquisito), e il post lo dice. È stata scelta perché Netflix ne ha pubblicato abbastanza da poter nominare ogni passaggio: ispezione, analisi della complessità, generazione della ladder, codifica, validazione e punteggio di qualità.

Cosa portarsi a casa. La dimostrazione più chiara di "dieci cose, non mille" al livello 1, e un buon esempio di come ammettere che lo zoom di livello 3 esce dal percorso tracciato.

Post completo: Anatomia di un Play: modellare Netflix in C4.

Esempio 3: Uber, una richiesta di corsa

Basato sulle comunicazioni pubbliche di Uber. Non è un documento di architettura ufficiale di Uber.

Livello 1. Al livello System Context, Uber è composta da tre piattaforme di prodotto (Mobility, Delivery, Freight) poggiate su un unico Marketplace condiviso, con sotto uno strato di piattaforme Foundation: Maps, Payments, identità e rischio, comunicazioni, la piattaforma di ML, il motore di workflow, lo storage, lo streaming, l'osservabilità e il compute. Tra gli attori esterni ci sono passeggeri, conducenti, clienti delle consegne, rider, esercenti, circuiti di pagamento, operatori di telecomunicazioni e autorità cittadine.

Livello 2. Lo zoom sui container segue una richiesta di corsa lungo il percorso di dispatch del Marketplace: l'edge gateway, un orchestratore dei viaggi che esegue ogni viaggio come istanza di workflow, il motore di matching, il pricing dinamico, il servizio ETA, lo stato dei conducenti, lo strato di storage e Kafka.

Livello 3. La vista dei componenti apre il motore di matching: un normalizzatore delle richieste che trasforma le coordinate in indici esagonali H3, uno scanner dell'offerta, un espansore ad anelli, un ranker dei candidati, un risolutore delle assegnazioni, il dispatcher delle notifiche e un percorso di fallback.

Cosa portarsi a casa. L'esempio di come disegnare un'azienda piattaforma al livello 1 senza disegnare ogni prodotto. Il Marketplace condiviso al centro dice sull'architettura di Uber più di quanto farebbe qualsiasi elenco di servizi.

Post completo: Anatomia di una corsa: modellare Uber in C4.

Esempio 4: Revolut, un bonifico internazionale

Basato sulle comunicazioni pubbliche di Revolut. Non è un documento di architettura ufficiale di Revolut.

Livello 1. Le comunicazioni pubbliche descrivono almeno otto sistemi di prodotto: Retail Banking, Business Banking, FX, Wealth and Trading, Credit, FinCrime, Onboarding e KYC, e il ledger centrale con il suo backbone di eventi. Intorno: circuiti delle carte, reti di pagamento (Faster Payments, SEPA, SWIFT), banche partner, autorità di regolamentazione e Google Cloud. Il diagramma rende evidente una cosa che un organigramma non mostrerebbe: FinCrime riceve frecce da ogni prodotto, quindi si trova sul percorso critico di tutti.

Livello 2. Lo zoom sui container segue un bonifico da EUR a GBP attraverso Retail Banking: le app mobili, l'API edge, un orchestratore dei bonifici con una macchina a stati esplicita, un ledger a partita doppia su PostgreSQL, il motore FX, la pipeline FinCrime, un connettore per ogni rete di pagamento, l'event store e le notifiche.

Livello 3. La vista dei componenti apre Sherlock, il motore antifrode: assemblaggio delle feature, un profile store in memoria, il model server, una policy decisionale, il riaddestramento notturno e un ciclo di feedback degli analisti.

Cosa portarsi a casa. È l'esempio più completo dei quattro. Aggiunge una timeline passo per passo tra i livelli 1 e 2 (con latenze chiaramente indicate come illustrative, non pubblicate) e una sezione "copia questo, salta questo" che dice quali decisioni un team con dieci servizi dovrebbe copiare e quali no.

Post completo: Anatomia di un Transfer: modellare Revolut in C4.

Un piccolo esempio da copiare

I quattro esempi sopra sono grandi di proposito. La maggior parte dei sistemi non lo è, quindi ecco un piccolo esempio di modello C4 su tutti e tre i livelli utili: la piattaforma e-commerce usata in tutta la nostra guida completa al modello C4. Copia la struttura, rinomina i box.

Livello 1: System Context

[Customer] --> [E-Commerce Platform] : Browses products, places orders
[Warehouse Staff] --> [E-Commerce Platform] : Manages inventory
[E-Commerce Platform] --> [Payment Gateway (Stripe)] : Processes payments
[E-Commerce Platform] --> [Shipping Provider (FedEx API)] : Creates shipments
[E-Commerce Platform] --> [Email Service (SendGrid)] : Sends notifications

Due tipi di utente, tre sistemi esterni, un solo box per tutto ciò che possiedi.

Livello 2: Container

[Single-Page Application (React)] --> [API Gateway (Kong)] : Makes API calls (HTTPS/JSON)
[API Gateway] --> [Order Service (Go)] : Routes requests
[API Gateway] --> [Product Service (Go)] : Routes requests
[API Gateway] --> [User Service (Go)] : Routes requests
[Order Service] --> [Order Database (PostgreSQL)] : Reads/writes orders
[Product Service] --> [Product Database (PostgreSQL)] : Reads/writes products
[User Service] --> [User Database (PostgreSQL)] : Reads/writes users
[Order Service] --> [Message Queue (Kafka)] : Publishes order events
[Notification Service (Go)] --> [Message Queue] : Consumes order events

Ogni box nomina la sua tecnologia, ogni freccia nomina il suo protocollo o il suo scopo, e gli archivi di dati sono disegnati come container.

Livello 3: Component (dentro l'Order Service)

[Order Handler] --> [Order Service] : Delegates business logic
[Order Service] --> [Order Repository] : Persists orders
[Order Service] --> [Payment Client] : Validates payment
[Order Service] --> [Inventory Client] : Checks stock availability
[Order Repository] --> [Order Database (PostgreSQL)] : SQL queries
[Payment Client] --> [Payment Gateway (Stripe)] : HTTPS/REST
[Inventory Client] --> [Product Service] : gRPC

Un solo container riceve un diagramma dei componenti, la stessa regola che seguono i quattro esempi grandi. I servizi Product e User sono semplici CRUD, quindi disegnarne l'interno non aggiungerebbe nulla che l'elenco delle cartelle non mostri già.

Per il ragionamento dietro ciascuna di queste scelte, vedi le guide per livello: cosa va in un diagramma di contesto di sistema, cosa va in un diagramma dei container e quando vale la pena disegnare un diagramma dei componenti. Qui abbiamo saltato il livello 4 per lo stesso motivo per cui lo fa la maggior parte dei team; la guida al diagramma di codice spiega quando si guadagna il suo posto.

Cosa hanno in comune i quattro

Messi uno accanto all'altro, i quattro esempi seguono la stessa manciata di abitudini. Nessuna è una regola del modello C4 in sé. Sono ciò che ha reso leggibili questi modelli.

Circa dieci box al livello 1. Quindici per Stripe, dieci per Netflix, otto per Revolut e, per Uber, tre piattaforme di prodotto su un unico Marketplace con le piattaforme Foundation sotto. Nessuna di queste aziende è piccola. I diagrammi di livello 1 restano piccoli perché raggruppano per sistema di prodotto, non per servizio.

Un solo percorso al livello 2. Ogni diagramma dei container mostra solo i container attraversati da un'azione. La vista dei container di Stripe non ha container di Billing o Atlas. Quella di Netflix non ha nulla di Studio Engineering. Non è un'omissione; quei container appartengono a un altro diagramma, per un'altra azione.

Un solo container al livello 3, scelto con onestà. Lo zoom sui componenti va sempre dove la documentazione pubblica è abbastanza profonda da disegnare componenti reali. Il post su Netflix dice apertamente che Cosmos è fuori dal percorso di riproduzione al momento della richiesta. Un esempio che nasconde questo tipo di scelta insegna la lezione sbagliata.

I sistemi esterni pesano quanto quelli interni. Circuiti delle carte, ISP, reti di pagamento, operatori di telecomunicazioni: in tutti e quattro, alcuni dei box più importanti sono cose che l'azienda non possiede. I connettori verso le reti di pagamento di Revolut sono i container il cui guasto non si può eliminare con l'ingegneria, ed è il diagramma a renderlo visibile.

Le decisioni stanno accanto ai box. Ogni esempio ha tre ADR, e ogni ADR spiega un box che un nuovo arrivato troverebbe sorprendente: perché Netflix ha Open Connect dove altri servizi di streaming usano una CDN commerciale, perché Revolut non ha Kafka, perché Stripe ha costruito su MongoDB invece di migrare altrove. Se vuoi il metodo per scriverli, la guida completa agli architecture decision record lo spiega.

Ogni box ha un owner. Ogni post chiude il suo modello con una mappa della ownership: quale team possiede quale sistema o container. È il passaggio che trasforma un diagramma in qualcosa che qualcuno ha la responsabilità di mantenere veritiero.

Modella il tuo sistema

Non servono i volumi di Stripe o il numero di servizi di Uber perché tutto questo si applichi. Gli stessi passaggi funzionano per un sistema con dieci servizi:

1. Scegli un'azione dell'utente che conta: il checkout, la registrazione, la cosa che fa scattare il pager di qualcuno alle 3 di notte.
2. Disegna il livello 1 con il tuo sistema come un unico box, ogni tipo di utente e ogni sistema esterno che quell'azione tocca. Punta a meno di quindici box.
3. Disegna il livello 2 per quell'unica azione. Solo i container che attraversa, ciascuno etichettato con la sua tecnologia, ogni freccia etichettata con un verbo e un protocollo.
4. Scegli un container per il livello 3, quello con cui un nuovo assunto farebbe più fatica, e disegna i suoi componenti principali.
5. Scrivi tre ADR per i tre box di cui qualcuno chiederà "perché è fatto così?".
6. Metti il nome di un team su ogni container.

Poi ripeti per l'azione successiva. Dopo tre o quattro azioni i diagrammi di livello 2 iniziano a sovrapporsi, e la sovrapposizione è il tuo vero diagramma dei container.

Ciò che i quattro esempi non possono mostrare è cosa succede sei mesi dopo, quando il codice si è spostato e i diagrammi no. È il problema attorno a cui è costruito archyl. Collega un repository e la scoperta tramite IA propone sistemi, container, componenti e relazioni da approvare invece di disegnarli da zero, e un drift score confronta poi il modello con il codice, così scopri quando è diventato obsoleto.

FAQ

Qual è un buon esempio di modello C4?

Un buon esempio di modello C4 traccia un'azione reale dell'utente attraverso i livelli da 1 a 3 e spiega i suoi box sorprendenti. I quattro esempi di questa pagina (Stripe, Netflix, Uber, Revolut) fanno esattamente questo, con un diagramma di livello 1 di circa dieci sistemi, un diagramma dei container limitato a un solo percorso e un solo zoom sui componenti. Per un sistema piccolo, l'esempio e-commerce qui sopra è un modello sensato.

Dove posso trovare un esempio di diagramma dei container C4?

Ognuno dei quattro post completi ha un diagramma dei container di livello 2: il core dei pagamenti di Stripe, la Streaming Platform di Netflix, il percorso di dispatch di Uber e il percorso dei bonifici di Revolut. Per un esempio svolto più piccolo, con una tabella di container e relazioni, vedi la guida al diagramma dei container C4.

Questi sono diagrammi di architettura ufficiali di Stripe, Netflix, Uber e Revolut?

No. Ogni modello si basa interamente sulle comunicazioni pubbliche dell'azienda, e ogni post completo indica dove i dettagli sono dedotti anziché dichiarati. Servono a mostrare come il modello C4 renda leggibile uno stack complesso, non a documentare come queste aziende funzionano oggi.

Gli esempi C4 hanno bisogno di tutti e quattro i livelli?

Raramente. Tutti e quattro gli esempi qui disegnano i livelli 1, 2 e 3 e si fermano. I diagrammi a livello di codice cambiano a ogni refactoring e di solito conviene generarli dal codice anziché disegnarli, ed è per questo che la maggior parte dei modelli C4 reali si ferma ai componenti.

Quanti elementi dovrebbe avere un diagramma di contesto di sistema C4?

Non c'è un limite ufficiale. In questi esempi, il livello 1 va da otto a quindici sistemi più i loro attori esterni, per aziende con centinaia o migliaia di servizi. Se il tuo ne richiede molti di più, probabilmente stai disegnando container al livello sbagliato, oppure ti serve una vista di system landscape che copra più sistemi.

Vuoi modellare il tuo sistema in C4? Prova archyl gratis con il piano Developer, senza carta di credito. Continua a leggere: Cos'è il modello C4? Una guida completa | Guida al diagramma di contesto di sistema C4 | Guida al diagramma dei container C4 | Guida al diagramma dei componenti C4 | Guida al diagramma di codice C4.