Architettura
Da app su singolo server a sistemi distribuiti globali. Scelte di storage, replication, streaming, orchestrazione, costi, e i case study che mostrano come si fa su larga scala.
Corso
Architettura di dati e sistemi, dalle fondamenta
Un corso di 80 lezioni che parte da 'cos'è un'app su un singolo server' e arriva a 'progetta un sistema globale multi-regione su tre scale.' Ricco di case study reali di engineering (Netflix, Uber, Stripe, Discord, Pinterest, Airbnb), ricco di diagrammi, e costruito sulle fondamenta di Designing Data-Intensive Applications, l'SRE workbook, e un decennio di post-mortem.
Pubblicate: 80 di 80
-
Lezione 1
Cos'è davvero l'architettura del software
Definizioni che non sono inutili. L'architettura come l'insieme delle decisioni costose da cambiare in seguito. La regola: 'se è difficile da cambiare, è architettura'.
-
Lezione 2
Requisiti funzionali e non funzionali
La trappola di concentrarsi sulle funzionalità. Le qualità che guidano l'architettura: latency, throughput, availability, durability, consistency, sicurezza, evolvibilità.
-
Lezione 3
Il modello C4: context, container, component, code
Una convenzione di diagrammi a quattro livelli di zoom che si adatta alle conversazioni reali sui sistemi.
-
Lezione 4
Architectural Decision Records (ADR)
Catturare le decisioni con le loro alternative e conseguenze. Il formato di Michael Nygard, su cui la maggior parte dei team ha convergito.
-
Lezione 5
I trade-off sono tutto
Latency contro throughput, consistency contro availability, semplice contro flessibile. Il catalogo dei trade-off con un nome e perché 'vogliamo tutto' è la richiesta più costosa che si possa fare in una riunione.
-
Lezione 6
La prima architettura: una web app single-server con database
Che aspetto ha un sistema funzionante alla scala da startup: una VM, un Postgres, un processo, e perché è un punto di partenza assolutamente rispettabile.
-
Lezione 7
Quando la prima architettura smette di bastare
I sintomi che dicono che l'app single-server ha raggiunto il suo soffitto. Contention sul database, deploy che causano outage, il backup giornaliero che dura più di un giorno.
-
Lezione 8
Tre case study di 'avremmo dovuto partire più semplici'
Stripe che resta su Postgres molto più a lungo di quanto la gente si aspettasse, la posizione di Shopify sul monolith, e il majestic monolith di Basecamp. Le ragioni per non over-engineerare presto.
-
Lezione 9
Perché i sistemi distribuiti sono difficili: le 8 fallacie
La lista di Peter Deutsch, riformulata per il 2026. La rete è affidabile, la latenza è zero, la banda è infinita, e come ciascuna fallacia rovina la settimana di qualcuno.
-
Lezione 10
Il teorema CAP, in pratica
Cosa dice davvero CAP, cosa non dice, e perché 'AP system' è mezza frase. Esempi reali: DNS, ledger bancari, Cassandra.
-
Lezione 11
PACELC: cosa CAP si è perso
L'estensione di Daniel Abadi. Anche in assenza di partition, scambi latency per consistency.
-
Lezione 12
Modelli di consistency: strong, eventual, causal, monotonic
Lo spettro delle garanzie che un sistema può offrire, con un esempio pratico che mostra cosa promette e cosa rompe ogni modello.
-
Lezione 13
Il tempo nei sistemi distribuiti: clock, ordinamento, vector clock
Il tempo fisico è una bugia. Lamport timestamp, vector clock, TrueTime di Google, e perché 'quando è successo' è una delle domande più difficili.
-
Lezione 14
Consensus: Paxos e Raft, in parole semplici
Le garanzie di safety/liveness dei protocolli di consensus, perché Raft ha rimpiazzato Paxos nei sistemi moderni, e i sistemi che dipendono da loro.
-
Lezione 15
Two-phase commit e i suoi problemi
Il protocollo da manuale per le transazioni distribuite, il problema del coordinator failure che lo perseguita, e perché i sistemi moderni si appoggiano invece al pattern Saga.
-
Lezione 16
Idempotency, exactly-once, at-least-once, at-most-once
Cosa promette davvero ogni garanzia di delivery, perché 'exactly-once' è per lo più una claim di marketing, e come il processing idempotente la rende irrilevante.
-
Lezione 17
Database relazionali: quando SQL è la risposta giusta
Postgres come default. ACID, schemi, join, la piattaforma stabile da vent'anni che fa girare in silenzio la maggior parte dei sistemi transazionali del mondo.
-
Lezione 18
Key-value store: Redis, DynamoDB, quando vincono
Pura velocità, pura semplicità. I casi d'uso in cui un key-value store è la risposta giusta: caching, sessioni, rate limit, leaderboard.
-
Lezione 19
Document store: MongoDB e l'ascesa, la caduta e la rinascita
Quando i dati annidati sono il modello, cosa costa lo schema-on-read, e le lezioni operative che MongoDB ha insegnato all'industria.
-
Lezione 20
Wide-column: Cassandra, ScyllaDB, BigTable
Il patto della 'scala infinita, schema legato alle query'. Cosa promettono i database wide-column, cosa sacrificano, e quando l'affare vale la pena.
-
Lezione 21
Database time-series: Influx, Timescale, Prometheus
Quando timestamp-più-valore è il 99% dei tuoi dati. Le ottimizzazioni che permettono ai time-series store di battere i database general-purpose di 10x o più.
-
Lezione 22
Graph database: Neo4j, quando le relazioni sono il dato
Le query che sono dolorose in SQL e banali in Cypher: amico-di-un-amico, shortest path, recommendation system costruiti sulla traversal delle relazioni.
-
Lezione 23
Vector database: Pinecone, Qdrant, l'era degli LLM
Gli embedding come nuovo indice, ricerca ANN (approximate nearest neighbor) e la nuova infrastruttura dello stack LLM 2024-2026.
-
Lezione 24
Polyglot persistence: quando mescolare
Quando la tua applicazione trae beneficio da più database, quando uno solo basta, e il costo operativo di gestire quattro datastore invece di uno.
-
Lezione 25
Pattern di replication: leader/follower, multi-leader, leaderless
Le tre famiglie di replication dei database, i trade-off che ciascuna fa tra consistency e availability, e dove ognuna si colloca nei sistemi reali.
-
Lezione 26
Replication lag e read-after-write consistency
Il bug dell'utente-ha-visto-dati-vecchi. Perché succede con la replicazione asincrona, e i pattern per prevenirlo: read-your-writes, sticky session, monotonic reads.
-
Lezione 27
Partitioning: per chiave, per hash, per range
Quando un singolo nodo non basta a contenere i dati, li si divide. Le tre strategie di partitioning e le query che ciascuna abilita.
-
Lezione 28
Hot key e il problema del rebalancing
L'utente celebrità con un milione di follower. Come individuare una hot key, tre strategie per gestirla, e perché fare rebalancing su un cluster live è più difficile di quanto sembri.
-
Lezione 29
Strategie di sharding e i loro tranelli
Application-level sharding, sharding nativo del database, Citus e Vitess. Le realtà pratiche di gestire un database SQL shardato.
-
Lezione 30
Split brain: cos'è e perché rovina tutto
La network partition in cui entrambe le metà di un cluster credono di essere il leader. Perché il quorum è l'unica difesa affidabile.
-
Lezione 31
Query cross-shard: fan-out contro co-location
Quando i dati sono divisi su molte macchine, ogni query ha un costo proporzionale al numero di shard che tocca. Le strategie per tenere quel numero basso.
-
Lezione 32
Caso reale: il viaggio di Discord da MongoDB a Cassandra a ScyllaDB
Come lo storage dei messaggi di Discord è passato da MongoDB a Cassandra a ScyllaDB nell'arco di dieci anni, cosa è costata ciascuna migrazione, e quali sono le lezioni per tutti gli altri.
-
Lezione 33
ETL contro ELT: dove vive il transform
L'ordine delle operazioni è cambiato quando i warehouse sono diventati economici. Perché ELT (extract, load, transform) ha rimpiazzato ETL nella maggior parte dei modern data stack.
-
Lezione 34
Fondamenti del batch processing: le lezioni di Hadoop
Cosa MapReduce ha azzeccato, cosa ha sbagliato, e la forma del batch processing che è sopravvissuta.
-
Lezione 35
Spark e il batch moderno
Il sostituto in-memory di Hadoop, le lezioni che ha conservato, e lo stack di batch processing moderno del 2026.
-
Lezione 36
La medallion architecture: bronze, silver, gold
Tre layer di raffinazione dei dati per un lakehouse. Perché ogni team dati moderno usa qualche versione di questa nomenclatura, anche quando non la chiama 'medallion'.
-
Lezione 37
Lakehouse: Delta, Iceberg, Hudi
Transazioni ACID su object storage. Le format wars del 2023-2025 e dove l'industria si è assestata nel 2026.
-
Lezione 38
Batch idempotente: rendere i job rieseguibili in sicurezza
Overwrite contro append contro upsert. Il pattern MERGE. Perché 'questo job è girato due volte' dovrebbe essere un non-evento.
-
Lezione 39
Backfilling e replay
Il momento in cui scopri un bug vecchio di sei mesi e devi rieseguire ogni giorno da allora. I pattern che rendono il backfill una routine invece di un incubo.
-
Lezione 40
Caso reale: come Netflix esegue il batch giornaliero su petabyte di dati
L'orchestratore Maestro, l'adozione di Iceberg, i layer di ottimizzazione dei costi che rendono possibile il batch giornaliero su petabyte.
-
Lezione 41
Perché lo streaming: bounded vs unbounded data
Lo spostamento concettuale dal batch allo streaming. Perché uno 'stream' al limite è solo un 'batch con batch molto piccoli', e perché quel limite cambia il design.
-
Lezione 42
Kafka: il log dominante
Perché Kafka è diventato la spina dorsale di integrazione dell'architettura moderna. Topic, partizioni, consumer group, offset e la garanzia at-least-once.
-
Lezione 43
Stream processing: Flink, Kafka Streams, Spark Structured Streaming
Tre engine per processare stream, quando ognuno è la scelta giusta, e perché Flink è la scelta pesante per processing stateful complesso.
-
Lezione 44
Event time contro processing time, watermark
I dati che arrivano in ritardo sono il problema dello streaming di cui nessuno ti avvisa. Event time, watermark, e i pattern che rendono corrette le aggregazioni a finestra.
-
Lezione 45
Semantica exactly-once negli stream
Cosa garantiscono davvero le Kafka transactions, il problema della source-sink coordination, i limiti, e perché exactly-once tra servizi è difficile.
-
Lezione 46
CDC (Change Data Capture) e il problema del dual-write
Debezium, Maxwell, AWS DMS. Il problema del dual-write e l'outbox pattern che lo risolve.
-
Lezione 47
Lambda vs kappa architecture
Il contesto storico: perché Lambda è esistita, perché Kappa l'ha sostituita, e quando Lambda ha ancora un suo posto nel 2026.
-
Lezione 48
Caso reale: le pipeline real-time di Uber (Marmaray, l'origine di Hudi)
L'evoluzione di Uber da batch-only a streaming-first, il problema dell'ingestion dei dati, e il progetto Hudi che ne è venuto fuori.
-
Lezione 49
Git per team di engineering: branching strategy che funzionano
Trunk-based, GitHub flow, gitflow. Le realtà su scala di team piccoli e grandi, quando ognuna calza, e i pattern sopravvissuti a 15 anni di pratica.
-
Lezione 50
Trunk-based development: perché la maggior parte dei team moderni è confluita qui
Branch a vita breve, feature flag, continuous integration. Il pattern adottato a scala da Google, Facebook e Microsoft, e cosa serve perché funzioni.
-
Lezione 51
CI per data pipeline: testare senza bruciare un cluster
Unit test sulle trasformazioni, integration test su sample data, il loop di sviluppo local-first. Perché la CI per i dati è diversa dalla CI per i web service.
-
Lezione 52
CD per i dati: pattern di deployment per batch e streaming
Blue-green, canary, dark launch. Perché i job di streaming hanno bisogno di pattern di deploy diversi rispetto ai servizi web, e come i job batch si deployano attraverso il loro schedule.
-
Lezione 53
Infrastructure as code: Terraform, Pulumi, CDK
Infrastruttura dichiarativa, il problema dello state file, il workflow GitOps. Tre tool e dove ognuno si incastra.
-
Lezione 54
Container: Docker per i lavori sui dati
Pattern di Dockerfile, multi-stage build, la base image giusta, gli image registry. I fondamentali sui container che ogni data engineer dovrebbe conoscere.
-
Lezione 55
Kubernetes per i dati: il buono, il cattivo, il necessario
Quando k8s è il tool giusto, quando è overkill, l'operator pattern, e le integrazioni Spark/Airflow che fanno funzionare il data engineering su Kubernetes.
-
Lezione 56
Caso reale: la pipeline di deployment di Stripe
Velocità di merge-to-deploy, la rete di sicurezza dei test automatici, la cultura del deploy-as-non-event. Cosa rivelano sul CI/CD a scala le pratiche di engineering pubblicate da Stripe.
-
Lezione 57
Orchestration in profondità: Airflow, Prefect, Dagster, Argo Workflows
I quattro contendenti, quando ciascuno vince, framing asset-oriented contro task-oriented, e la decisione managed contro self-hosted.
-
Lezione 58
Orchestrazione asset-oriented (la lezione di Dagster)
Modellare tabelle e file come oggetti first-class. Perché questo approccio paga su scala e cosa cambia nel modo in cui i team pensano alle pipeline.
-
Lezione 59
Osservabilità per i dati: log, metriche, trace, lineage
I tre pilastri più il lineage. OpenTelemetry, Datadog, Honeycomb. Tool di lineage (Marquez, OpenLineage, DataHub).
-
Lezione 60
SLO, SLA, error budget per i prodotti dati
Il framework SRE di Google applicato ai dati: 'la dashboard si aggiorna entro le 9 del mattino' come impegno misurabile e difendibile.
-
Lezione 61
Data quality: Great Expectations, Soda, dbt tests
Test dichiarativi sui dati. I tre tool, i pattern che funzionano, e la trappola dell'over-testing.
-
Lezione 62
Incident response: runbook, postmortem, la cultura blameless
Il ciclo di vita degli incidenti secondo Google SRE, il formato di runbook che funziona, il postmortem blameless, e perché aggiustare i processi batte aggiustare le persone.
-
Lezione 63
On-call per la data engineering
Le realtà di stare in rotazione. Igiene del pager, escalation, hand-off, e perché conviene avere meno alert.
-
Lezione 64
Caso reale: come Airbnb gestisce la sua data platform
La storia delle origini di Airflow (Airbnb l'ha costruito), il metrics layer Minerva, il sistema di data discovery Dataportal, e il framework di data quality. Cosa rivelano le pratiche pubblicate di Airbnb sul gestire una data platform su scala.
-
Lezione 65
Il costo del cloud: il modello dell'iceberg
Il compute è la voce che tutti guardano. Storage, egress, NAT, cross-AZ, request count e log ingestion sono l'iceberg sotto la linea di galleggiamento. Dove finisce davvero la bolletta, e perché esiste il FinOps.
-
Lezione 66
Ottimizzazione del costo dello storage: tiering, lifecycle, compaction
I dati hot sono una piccola frazione del totale, ma raccolgono la maggior parte degli accessi. Tiering, lifecycle policy e Parquet compaction sono le leve che allineano il costo dello storage al modo in cui i dati vengono davvero usati.
-
Lezione 67
Ottimizzazione del costo del compute: Spot, autoscaling, right-sizing
Tre leve muovono la maggior parte della bolletta di compute: Spot instance per i workload interrompibili, autoscaling che risponde al carico senza thrashing e right-sizing delle VM, che sono per lo più sovradimensionate. La reserved capacity copre la baseline prevedibile.
-
Lezione 68
Costo del network: egress, cross-AZ, la bolletta a sorpresa
La voce più trascurata sulla bolletta del cloud. Pricing dell'egress, traffico cross-AZ, NAT gateway, VPC endpoint e i pattern architetturali che evitano che il network diventi il costo dominante.
-
Lezione 69
Scaling 10x: cosa si rompe, cosa sopravvive
L'esercizio del 10x. Quali componenti scalano linearmente con la potenza di calcolo, quali sbattono contro un muro, e i pattern architetturali che sopravvivono a un salto di un ordine di grandezza nel carico.
-
Lezione 70
Strategie di caching: CDN, applicazione, database
I tre livelli di caching, i quattro pattern canonici di cache, il problema dell'invalidazione, e come difendere una hot key dalla stampede che fa cadere il database.
-
Lezione 71
La decisione del 'ricostruirlo a meno'
Quando la fattura del vendor diventa abbastanza dolorosa da far sembrare attraente costruirlo in casa. La matematica onesta, quando ricostruire funziona, quando no, e l'ibrido che spesso vince.
-
Lezione 72
Caso reale: come Pinterest ha tagliato a metà il costo della sua data infra
Un programma pluriennale di cost reduction su una piattaforma dati AWS multi-petabyte. Storage tiering, efficienza Spark, riscrittura delle query, right-sizing, e i cambiamenti culturali che hanno reso permanenti i risparmi.
-
Lezione 73
Microservices: quando, quando no, il ritorno del monolith
Il boom dei microservices del 2015-2020, il pushback dal 2021 in poi, e il modular monolith come via di mezzo. La legge di Conway, la tassa dei sistemi distribuiti, e come scegliere in base alla dimensione del team e al profilo di scaling.
-
Lezione 74
Event-driven architecture: saga, choreography, orchestration
Servizi che si parlano emettendo eventi, la scelta tra choreography e orchestration, il pattern saga, e il toolset 2026 (Temporal, Step Functions, Camunda, Argo).
-
Lezione 75
Deployment multi-region: active-active, active-passive, follow-the-sun
Perché i team vanno in multi-region (latenza, DR, compliance, capacità), le tre forme di deployment, i problemi difficili (replica, conflitti, costo), e quando non vale la pena.
-
Lezione 76
Disaster recovery: RTO, RPO, il drill
Cosa significa davvero in pratica il disaster recovery. Le quattro DR tier, RTO e RPO come manopole di design, e la disciplina del drill che dimostra che il piano funziona.
-
Lezione 77
Security architecture: least privilege, defense in depth
I principi di sicurezza di cui ogni sistema ha bisogno come architettura portante. Least privilege, defense in depth, zero trust, e i controlli IAM e di rete che trasformano i principi in realtà.
-
Lezione 78
Privacy e compliance: GDPR, CCPA, data residency
Le normative sulla privacy come driver architetturali. Diritto all'oblio, data residency, customer-managed keys, e l'infrastruttura di consent e audit che i framework di compliance richiedono.
-
Lezione 79
Architettura di una ML platform: feature store, model registry, serving
I cinque layer su cui una ML platform moderna si è standardizzata, il problema del train-serve skew per cui è stato inventato il feature store, e il calcolo build-versus-buy per ogni layer nel 2026.
-
Lezione 80
Capstone: progettare un'architettura completa per un'azienda fittizia a tre scale
Ottanta lezioni di system architecture, condensate in un singolo esercizio di design. La stessa azienda SaaS fittizia, tre scale, tre architetture, e un tour guidato di cosa cambia e perché. La lezione di chiusura del corso.