Capstone: progettare un'architettura completa per un'azienda fittizia a tre scale

Ottanta lezioni. Dieci moduli. Circa 150.000 parole. Il lettore che ha seguito dalla lezione 1 ha, a questo punto, un vocabolario di lavoro e un framework decisionale per la system architecture. Quello era il livello a cui il corso puntava, e il resto di questa lezione è l’esercizio che rende concreto quel framework.

L’esercizio è una singola azienda fittizia, progettata tre volte a tre scale. L’azienda è una piattaforma SaaS B2B che ingerisce eventi dalle applicazioni dei clienti, esegue analytics su quegli eventi, ed espone sia dashboard sia un’API. Scegli qualunque forma ti permetta di riempire i vuoti: uno strumento di product analytics, un vendor di osservabilità, una customer data platform, un servizio di feature flagging. Il business esatto non importa. Quello che importa è che il workload sia riconoscibile: ingest, store, query, serve.

Le tre scale sono 100 utenti alla settimana uno, 100.000 utenti alla series A, e 100 milioni di utenti nella fase SaaS matura. A ogni scala l’architettura è progettata interamente: componenti, infrastruttura, forma del team, costo mensile. La parte interessante non è nessuno dei singoli design. La parte interessante è cosa cambia tra le scale e perché. Ogni shift è una decisione architetturale che il corso ha coperto. Il capstone è la chance di vederle impilate.

Scala 1: 100 utenti, settimana uno della startup

flowchart LR
    User[Customer browser] --> CDN[CDN]
    CDN --> Static[Static frontend]
    User --> API[Single VM<br/>API + worker]
    API --> DB[(Postgres on the same VM)]
    API --> Stripe[Stripe<br/>billing]
    API --> Sendgrid[Sendgrid<br/>email]

Componenti:

Una virtual machine che fa girare il server API e un processo worker di background fianco a fianco. Potrebbe essere un’istanza EC2 a 4 core, un box Hetzner, o un droplet DigitalOcean. Costo: da 50 a 100 EUR al mese.
Postgres, che gira sulla stessa VM, con backup giornalieri verso object storage.
Un frontend statico (Next.js o un export statico Astro, la forma preferita dalla lezione 6) su un CDN.
Stripe per il billing. Sendgrid o Postmark per l’email transazionale.
Sentry per l’error tracking, free tier. Un account Grafana Cloud gratuito con metriche Prometheus di base, o anche solo nulla per ora.

Costo mensile totale: da 50 a 100 EUR per l’infrastruttura, più qualunque cosa Stripe e Sendgrid addebitino in base al volume. Team: due o tre founder, nessuna operations dedicata.

Cosa deliberatamente non c’è. Niente Kubernetes. Niente microservizi. Niente Kafka. Niente data warehouse. Niente read replica. Niente cache. Nessuna pipeline CI/CD oltre uno script di deploy in Github Actions. Nessuno stack di osservabilità oltre Sentry e le metriche della VM stessa. Nessuna rotazione on-call, perché ci sono tre persone e sono tutte in on-call di default.

L’argomento architetturale per questa forma è l’argomento delle lezioni 6 e 7. Un singolo Postgres su una singola VM serve business reali fino a un traffico sorprendentemente alto (l’architettura di GitLab pre-2018, l’architettura di Stack Overflow come documentata nel loro famoso post del 2016). La tassa di premature-optimisation per mettere Kubernetes e Kafka davanti ai primi cento utenti è enorme, e l’opzionalità che preserva è illusoria perché il business pivotterà prima che nulla di questo conti. La forma è quella che la lezione 8 ha chiamato started-simpler. È anche quella che sopravvive al contatto con la realtà a questo stadio, perché la realtà a questo stadio è che i founder devono spedire feature, non far girare infrastruttura.

Scala 2: 100.000 utenti, series A

flowchart LR
    User[Customer browser] --> CDN[CDN]
    CDN --> Static[Static frontend]
    User --> LB[Load balancer<br/>multi-AZ]
    LB --> API1[API pod]
    LB --> API2[API pod]
    API1 --> Cache[(Redis<br/>cache + sessions)]
    API2 --> Cache
    API1 --> Primary[(Postgres<br/>primary)]
    API2 --> Primary
    API1 --> Replica[(Postgres<br/>read replica)]
    API2 --> Replica
    Primary -.replication.-> Replica
    API1 --> Kafka[Kafka<br/>event spine]
    Kafka --> Worker[Worker pool]
    Worker --> Primary
    Worker --> S3[(Object storage<br/>files + backups)]
    Worker --> WH[(Warehouse<br/>BigQuery / Snowflake)]
    API1 --> Obs[Observability stack<br/>Datadog / Grafana Cloud]

Componenti:

Postgres, ora un servizio managed (RDS o Aurora), con una o due read replica. L’applicazione è stata refattorizzata per indirizzare le letture verso le replica dove la consistency eventuale è accettabile (lezione 25 e lezione 26).
Un worker pool separato per i job di background, che gira sullo stesso cluster Kubernetes degli API pod o su un’offerta serverless come ECS Fargate.
Redis per cache e session storage (lezione 18). Letture hot che prima colpivano Postgres ora colpiscono Redis. La cache invalidation è il primo problema duro del team.
Kafka come event spine (lezione 42). Gli eventi dei clienti fluiscono in Kafka e sono consumati dal worker pool, dal warehouse loader, e da qualsiasi altro sistema downstream. La forma event-driven della lezione 47 inizia a ripagare.
Object storage per i file caricati dagli utenti e per i backup del database. CDN davanti al frontend statico e a qualsiasi media user-facing.
Deployment multi-AZ in una region (lezione 76). Il primary Postgres, la replica, e i nodi Kubernetes sono distribuiti su tre availability zone. L’outage di una singola AZ non abbatte la piattaforma.
Un warehouse (BigQuery, Snowflake, o Redshift) con dati caricati dal database operazionale via CDC (lezione 46) o ELT schedulato (lezione 33) più eventi da Kafka.
Una pipeline CI/CD per il codice applicativo (lezione 51 e 52) e Terraform o Pulumi per l’infrastruttura (lezione 53).
Uno stack di osservabilità di base: Datadog o Grafana Cloud, metriche Prometheus, logging strutturato, distributed tracing sui critical request path (lezione 59). SLO definiti per i top tre flussi user-facing (lezione 60).

Costo mensile totale: da 10.000 a 30.000 EUR, a seconda della forma del traffico e di quanto sia stato over-engineerato. Team: da 10 a 30 ingegneri, un ingegnere operations o SRE dedicato che probabilmente ha anche responsabilità di prodotto.

Gli shift architetturali dalla scala 1 sono esattamente quelli che il corso ha coperto. Read replica perché il traffico in lettura ora le giustifica. Cache Redis perché il budget di latenza per le query più comuni non consente un altro round-trip al database. Kafka perché il numero di integrazioni ha superato la soglia oltre la quale le connessioni point-to-point diventano un groviglio. Multi-AZ perché lo SLA che i contratti ora menzionano lo richiede. Un warehouse perché le query analitiche stanno iniziando a interferire con il database operazionale. Una pipeline CI/CD perché il team è abbastanza grande da rendere i deploy manuali una fonte di outage.

Cosa ancora non c’è. Niente multi-region. Niente sharding. Niente microservizi, oltre a un paio di piccoli servizi che si sono guadagnati l’indipendenza per genuino bisogno di caratteristiche di scaling diverse. Nessun platform team dedicato, nessun team SRE dedicato, nessun team di sicurezza dedicato. Niente SOC 2, anche se l’azienda sta iniziando il processo. Nessuna flotta GPU. L’architettura ha più parti della scala 1, ma ogni parte si è guadagnata il suo posto risolvendo un problema che il team stava effettivamente avendo.

Scala 3: 100 milioni di utenti, SaaS maturo

flowchart TB
    subgraph Edge[Edge layer]
        CDN[Global CDN]
        WAF[WAF + DDoS protection]
    end
    subgraph US[US region]
        US_LB[Regional load balancer]
        US_API[API services<br/>Kubernetes cluster]
        US_DB[(Sharded Postgres / Vitess)]
        US_Cache[(Redis cluster)]
        US_Kafka[Kafka cluster]
    end
    subgraph EU[EU region]
        EU_LB[Regional load balancer]
        EU_API[API services<br/>Kubernetes cluster]
        EU_DB[(Sharded Postgres / Vitess)]
        EU_Cache[(Redis cluster)]
        EU_Kafka[Kafka cluster]
    end
    subgraph Data[Data platform]
        Lake[(Lakehouse<br/>Iceberg / Delta)]
        WH[(Warehouse)]
        ML[ML platform]
    end
    Edge --> US_LB
    Edge --> EU_LB
    US_Kafka -.MirrorMaker.-> EU_Kafka
    US_Kafka --> Lake
    EU_Kafka --> Lake
    Lake --> WH
    Lake --> ML

Componenti:

Postgres shardato (via Vitess o Citus) o una migrazione a un database distribuito (Spanner, CockroachDB, Aurora). La decisione tra shardare il Postgres esistente e migrare verso un database distribuito è stato il progetto multi-trimestre descritto nella lezione 29, ed entrambi gli esiti sono difendibili.
Multi-region. Active-active per il tier read-heavy, active-passive per i tier che non possono tollerare la complessità della conflict resolution (lezione 75). I clienti sono instradati alla loro region più vicina via GeoDNS, e i dati sono replicati tra le region con qualunque modello di consistency il team abbia deciso di accettare.
Confini di microservizi che corrispondono ai confini dei team (lezione 73). L’architettura non è “microservizi” perché i microservizi erano l’obiettivo; sono microservizi perché il team è ora di centinaia di ingegneri, e il costo sociale di un singolo deployable condiviso da cento ingegneri è maggiore del costo operazionale di cento deployable coordinati attraverso una service mesh.
Una data platform completa: lakehouse (lezione 37) su object storage con Iceberg o Delta, un warehouse per i workload di BI, un feature store, un model registry, un experiment tracker, e l’infrastruttura di serving della lezione 79. Le pipeline streaming (lezioni da 41 a 48) alimentano tutto in quasi real time.
Uno stack di osservabilità completo con dashboard custom per team, distributed tracing su ogni servizio, SLO ed error budget per ogni user journey critico, log retention scalata per conformarsi ai requisiti regolatori che l’azienda ora ha.
Platform team dedicati: un team di developer experience che possiede CI/CD e developer tooling, un data platform team che possiede il warehouse e il lakehouse, un team SRE che possiede la incident response e il programma on-call, un team di infrastruttura che possiede Kubernetes e gli account cloud sottostanti, un team di sicurezza che possiede le certificazioni di compliance e il vulnerability management.
Certificazioni di compliance: SOC 2 Type II, ISO 27001, PCI DSS se l’azienda tocca dati di carta direttamente, programmi GDPR e CCPA con l’infrastruttura di data residency, deletion, e consent che quelli richiedono (lezione 78). Il programma di compliance è di per sé una voce di bilancio multi-milione di euro.
Un programma formale di ottimizzazione costi (Modulo 9), con una funzione FinOps, review mensile dell’unit economics, gestione di reserved instance e savings plan, storage tiering, e gate espliciti su qualsiasi cambio architetturale che impatti materialmente la bolletta.

Costo mensile totale: una frazione del fatturato. Le shop ben gestite tengono il costo dell’infrastruttura sotto il cinque percento del fatturato a questa scala; le shop meno ben gestite sono al quindici percento e il CFO sta facendo domande puntute. Team: centinaia di ingegneri, con i platform team dedicati di sopra che rappresentano dal dieci al venti percento dell’organico.

Gli shift architetturali dalla scala 2 sono di nuovo quelli che il corso ha coperto. Sharding perché il pattern Postgres single-primary ha colpito il suo soffitto (lezione 29). Multi-region perché i clienti più grandi non firmeranno senza (lezione 75). Microservizi perché il confine del team (lezione 73) lo richiede. Certificazioni di compliance perché la motion di vendita enterprise le richiede (lezione 78). Il programma di ottimizzazione costi perché a questa scala mezzo percento del fatturato è denaro vero.

Cosa speriamo sia ancora riconoscibile dalla scala 1: Postgres è ancora il database, anche se è shardato o avvolto in Vitess o sostituito con un sistema distribuito Postgres-compatible. Kafka è ancora la spine. Il frontend statico è ancora servito da un CDN. La forma del sistema è la stessa; le costanti sono diverse. Quello è il filo che il corso ha cercato di tirare dalla lezione 1.

Cosa sai ora

Un paragrafo per modulo, in italiano semplice, su cosa il lettore può ora ragionare.

Modulo 1, lezioni da 1 a 8: fondamenta. Cos’è l’architettura, requisiti funzionali contro non funzionali, il modello C4, gli architectural decision record, il linguaggio dei trade-off, la prima architettura, e quando smette di funzionare. Puoi guardare un sistema e dire quali sono i suoi quality attribute, dove sono stati fatti i trade-off, e che tipo di sistema è. Sai scrivere un ADR.

Modulo 2, lezioni da 9 a 16: teoria dei sistemi distribuiti. Le otto fallacie, CAP, PACELC, modelli di consistency, tempo e clock, consenso, two-phase commit, semantica di delivery. Puoi leggere la documentazione di un database e capire cosa promette e cosa no. Puoi discutere con un vendor sulla loro caratterizzazione CAP senza bluffare.

Modulo 3, lezioni da 17 a 24: primitivi di storage. Relazionale, key-value, documento, wide-column, time-series, graph, vector, polyglot persistence. Sai in cosa ogni forma è buona, in cosa è cattiva, e perché un sistema reale di solito ne usa tre.

Modulo 4, lezioni da 25 a 32: replication e partitioning. Pattern di replica, replication lag, partitioning, hot key, strategie di sharding, split-brain, query cross-shard, e il case study di Discord. Puoi ragionare su una roadmap di scaling di un database.

Modulo 5, lezioni da 33 a 40: batch. ETL contro ELT, fondamenta del batch, Spark, l’architettura medallion, il lakehouse, batch idempotente, backfill, e il case study di Netflix. Puoi progettare una pipeline batch che non corrompe il warehouse al suo terzo retry.

Modulo 6, lezioni da 41 a 48: streaming. Perché lo streaming, Kafka, stream processor, event-time e watermark, exactly-once, CDC e l’outbox, lambda contro kappa, e il case study di Uber. Puoi leggere un diagramma di architettura streaming e capire i trade-off in ogni box.

Modulo 7, lezioni da 49 a 56: deployment. Branching Git, trunk-based development, CI e CD per i dati, IaC, Docker, Kubernetes, e il case study di Stripe. Puoi prendere un team che deploya a mano il venerdì e accompagnarlo lungo il percorso per deployare venti volte al giorno.

Modulo 8, lezioni da 57 a 64: operations. Orchestration, orchestration asset-oriented, osservabilità, SLO ed error budget, qualità dei dati, incident response, on-call, e il case study di Airbnb. Puoi prendere una piattaforma esistente e trasformarla da “una pila di pipeline” in “qualcosa che un team può far girare”.

Modulo 9, lezioni da 65 a 72: costi. L’iceberg dei costi, costi di storage, costi di rete, right-sizing del compute, costo delle query, costi GPU, il problema del data egress, e il calcolo rebuild-versus-buy. Puoi leggere una bolletta cloud e sapere cosa chiedere.

Modulo 10, lezioni da 73 a 80: preoccupazioni di scaling-out. Confini dei microservizi, legge di Conway, pattern multi-region, alta disponibilità oltre il multi-AZ, considerazioni regolatorie e di compliance, la ML platform, e questo capstone. Puoi unirti a una conversazione di architettura senior e seguirla.

Quello è il vocabolario di lavoro. Se sia abbastanza dipende da cosa il lettore farà con esso dopo.

Dove andare dopo

Cinque raccomandazioni concrete per cosa leggere dopo questo corso.

Designing Data-Intensive Applications, di Martin Kleppmann. Leggilo da copertina a copertina. Il corso era un tour; il libro è la profondità. Ogni argomento dei Moduli da 2 a 6 ha un capitolo che va più a fondo, e molti riferimenti in questo corso puntano indietro a esso. L’edizione 2017 è ancora il testo canonico nel 2026.

The SRE Book e The SRE Workbook, entrambi gratuiti su https://sre.google/books/. Le pratiche pubblicate dal team SRE di Google su come far girare grandi sistemi. Il corso ha coperto i concetti SRE (SLO, error budget, on-call, incident response) a livello architetturale; questi libri sono la profondità da praticante. Il Workbook in particolare è pieno di template ed esempi lavorati che si traducono direttamente in runbook.

Engineering blog. Iscriviti ai team di engineering che pubblicano i cui case study il corso ha attinto: Netflix Tech Blog, Uber Engineering, Stripe Engineering, Discord Engineering, Pinterest Engineering, Airbnb Engineering, Cloudflare Blog, Figma Engineering. Il rapporto segnale-rumore è alto; un anno di lettura rinfrescherà ed estenderà la maggior parte del contenuto di questo corso.

Gli altri corsi su questo sito. Questo corso è la lente architetturale; il corso SQL Server copre il database layer in profondità, il corso PySpark copre il moderno engine batch e streaming, e il corso Python copre i layer applicativo e ML. Insieme sono il toolbox completo del data engineering.

Un workload reale. Il loop di apprendimento più forte è quello in cui il lettore prende un sistema reale al suo lavoro, applica il framework di questo corso, trova i trade-off che sono stati fatti implicitamente, e o li documenta come ADR o propone cambiamenti che giustificherebbero un trade-off diverso. Il contenuto del corso passa dal vocabolario passivo alla pratica attiva nel momento in cui viene usato.

Chiusura

Ora hai il vocabolario. Puoi leggere un job posting, un pitch di un vendor, un post di engineering blog, un diagramma di architettura, o lo schizzo a lavagna di un ingegnere senior, e puoi seguire. Puoi fare la domanda che espone l’assunzione. Puoi nominare il trade-off che è stato fatto implicitamente. Puoi schizzare la tua architettura e argomentare per le scelte che hai fatto. Quello è ciò per cui ottanta lezioni di system architecture sono servite.

Il resto è pratica. I sistemi che muovono il mondo sono quelli che sono sopravvissuti al contatto con la realtà, e la realtà è ciò con cui lavorerai a partire da domani. Le costanti differiscono. Le forme no. Vai a costruire qualcosa.

Citazioni e letture aggiuntive

Martin Kleppmann, “Designing Data-Intensive Applications”, O’Reilly Media, 2017, https://dataintensive.net/ (consultato 2026-05-01). Il riferimento di profondità per quasi ogni argomento di questo corso.
Beyer, Jones, Petoff, Murphy (eds.), “Site Reliability Engineering: How Google Runs Production Systems”, O’Reilly Media, 2016, gratis su https://sre.google/sre-book/table-of-contents/ (consultato 2026-05-01). Il testo SRE fondazionale.
Beyer, Murphy, Rensin, Kawahara, Thorne (eds.), “The Site Reliability Workbook: Practical Ways to Implement SRE”, O’Reilly Media, 2018, gratis su https://sre.google/workbook/table-of-contents/ (consultato 2026-05-01). Il volume compagno hands-on.
Netflix Tech Blog, https://netflixtechblog.com/ (consultato 2026-05-01).
Uber Engineering, https://www.uber.com/blog/engineering/ (consultato 2026-05-01).
Stripe Engineering, https://stripe.com/blog/engineering (consultato 2026-05-01).
Discord Engineering, https://discord.com/category/engineering (consultato 2026-05-01).
Pinterest Engineering, https://medium.com/pinterest-engineering (consultato 2026-05-01).
Airbnb Engineering, https://medium.com/airbnb-engineering (consultato 2026-05-01).
Cloudflare Blog, https://blog.cloudflare.com/ (consultato 2026-05-01).
Figma Engineering, https://www.figma.com/blog/engineering/ (consultato 2026-05-01).