Kafka non è un message broker qualsiasi: è il sistema nervoso distribuito che tiene in piedi Netflix, LinkedIn e Uber. Gestisce milioni di eventi al secondo, non ne perde uno, mantiene l’ordine garantito per partizione. Questa prima puntata spiega i concetti fondamentali — topic, partizioni, offset, consumer group — usando come filo narrativo il caso Smart City del corso Advanced Data Modeling del Politecnico di Torino: 50 stazioni ARPA Piemonte, dati ambientali in tempo reale, pipeline completa verso InfluxDB e Grafana. Decima puntata del percorso Stack Digitale 2026.
Immagina di essere il team tecnico di un’agenzia ambientale regionale. Hai 50 stazioni meteo e di qualità dell’aria sparse sul territorio piemontese. Ogni cinque minuti, ciascuna stazione invia misurazioni di PM10, PM2.5, NO₂, O₃, temperatura, umidità e rumore in dB. Cinquanta stazioni per dodici letture l’ora, trecentocinquantanove giorni — circa 5 milioni di data point all’anno. Come li gestisci?
La risposta ovvia — “li scrivo direttamente nel database” — funziona finché il volume è basso. Quando le stazioni diventano cinquecento, o i sensori iniziano a mandare dati ogni trenta secondi invece che ogni cinque minuti, o vuoi che lo stesso evento venga elaborato da tre sistemi diversi contemporaneamente (InfluxDB per le serie temporali, Elasticsearch per gli alert, un servizio di notifica per i picchi critici), quel modello crolla. Kafka è la soluzione a quel problema. E non solo: è la soluzione che Netflix, LinkedIn e Uber hanno scelto quando hanno affrontato la stessa sfida, moltiplicata per centinaia di milioni di utenti.
Cos’è Apache Kafka: non un message broker, un log distribuito
La definizione più comune di Kafka — “message broker” — è tecnicamente imprecisa e praticamente fuorviante. Un message broker classico (RabbitMQ, ActiveMQ) riceve un messaggio, lo consegna al destinatario, lo cancella. Kafka funziona diversamente: i messaggi vengono scritti in un log persistente, ordinato e immutabile — e ci rimangono per un periodo configurabile (di default 7 giorni). I consumer leggono dal log alla velocità che preferiscono, da qualsiasi punto, quante volte vogliono.
Questa differenza strutturale ha conseguenze enormi. Con un broker classico, se il consumer è offline quando arriva il messaggio e non c’è un sistema di code robusto, il messaggio si perde. Con Kafka, il messaggio è nel log: il consumer può riprenderlo quando vuole, tornare indietro nel tempo, rileggere gli ultimi sei mesi di eventi per riaddestrare un modello ML, collegare un nuovo servizio che deve processare tutta la storia degli eventi. È questa persistenza e riproducibilità che rende Kafka fondamentalmente diverso da qualsiasi altro sistema di messaggistica.
Il modello a log: perché LinkedIn ha inventato Kafka
Kafka è nato in LinkedIn nel 2011 per risolvere un problema preciso: ogni azione di ogni utente — visualizzazione profilo, click su un link, connessione accettata — doveva arrivare in tempo reale a dozzine di sistemi diversi (raccomandazioni, analytics, feed, notifiche). I broker classici non reggevano né il volume né la necessità di avere più consumer indipendenti sullo stesso stream. La soluzione è stata modellare il problema come un log di database — append-only, ordinato, distribuito — anziché come una coda di messaggi.
I quattro concetti che devi capire
L’architettura Kafka si comprende attraverso quattro concetti. Una volta che li hai chiari, tutto il resto è dettaglio operativo.
Topic: il canale logico
Un topic è il canale logico dove i messaggi vengono pubblicati — l’equivalente di un “argomento” o di una “categoria”. Nel progetto Smart City del Poli esiste un topic chiamato sensor-data: tutte le letture di tutte le stazioni ARPA vanno in quel topic, indipendentemente dalla stazione o dal tipo di sensore. Un altro progetto potrebbe avere topic separati per tipo (pm10-readings, temperature-readings) — la scelta dipende da come vuoi organizzare i consumer.
Partizione e offset: il parallelismo e l’ordine
Ogni topic è suddiviso in partizioni — sottosequenze fisicamente separate sul disco, distribuite tra i broker del cluster. Le partizioni sono il meccanismo di parallelismo di Kafka: più partizioni, più consumer possono leggere in parallelo, più alto è il throughput massimo raggiungibile. Come si vede nel diagramma qui sopra, il topic sensor-data ha tre partizioni (P0, P1, P2): ogni partizione è una sequenza indipendente di messaggi con il proprio contatore — l’offset. L’offset è il numero progressivo che identifica ogni messaggio all’interno della sua partizione: offset 77 significa “il 78° messaggio scritto in questa partizione” (il conteggio parte da zero). L’ordine è garantito all’interno di una partizione, non tra partizioni diverse — un dettaglio importante per il design dei producer.
Consumer Group: il parallelismo lato lettura
Un consumer group è un insieme di consumer che cooperano per leggere un topic: Kafka garantisce che ogni messaggio venga consegnato a un solo consumer all’interno del gruppo. Nel diagramma, il Gruppo A (InfluxDB Writer) ha tre consumer — uno per partizione: Consumer 1 legge solo P0, Consumer 2 solo P1, Consumer 3 solo P2. Il Gruppo B (Alert Service) ha un solo consumer che legge tutte le partizioni. Entrambi i gruppi ricevono tutti i messaggi del topic, ma in modo indipendente — aggiungere un consumer group non rallenta gli altri. Questo è il superpotere di Kafka: lo stesso stream di dati può essere consumato simultaneamente da sistemi completamente diversi, ognuno alla propria velocità.
Il progetto Smart City: Kafka in un caso d’uso reale
Il progetto P1 del corso Advanced Data Modeling del Politecnico di Torino è la dimostrazione pratica di tutti questi concetti. Lo scenario: il team tecnico di un’agenzia ambientale regionale deve gestire dati in streaming da 50 stazioni fisse con 12 letture/ora ciascuna — circa 5 milioni di data point l’anno. Kafka è il primo layer della pipeline dopo i sensori.
La pipeline mostrata sopra segue questo flusso: le 50 stazioni inviano ogni cinque minuti le misurazioni ambientali (PM10, PM2.5, NO₂, O₃, temperatura, umidità, rumore) a Kafka come eventi JSON. Un consumer group legge da Kafka e scrive le serie temporali in InfluxDB — circa 5 milioni di data point all’anno. Un secondo consumer group sincronizza i metadati delle stazioni (geolocalizzazione GPS, modello sensore, soglie configurate) in MongoDB. Un terzo consumer indicizza in Elasticsearch gli eventi operativi: scattò un alert, fu eseguita una manutenzione, fu rilevata un’anomalia. Grafana interroga InfluxDB e Elasticsearch per il dashboard operativo con mappe, trend e soglie OMS. Quattro tecnologie diverse, tutte alimentate dallo stesso stream Kafka — senza che nessuna sappia dell’esistenza delle altre.
Confluent Cloud: Kafka senza installare nulla
Installare Kafka in locale richiede Java, Zookeeper (o KRaft nelle versioni recenti), la configurazione del broker e almeno venti minuti di terminale. Confluent Cloud — il servizio gestito della società fondata dai creatori di Kafka — offre un cluster funzionante in due minuti, con piano gratuito che include storage e messaggi sufficienti per sviluppo e sperimentazione.
Lo screenshot mostra il topic sensor-data nella dashboard Confluent Cloud — esattamente il topic del progetto P1, creato il 9 maggio 2026. Il tab Messages mostra 340 messaggi prodotti nell’ultima ora e 631 consumati — un consumer group sta processando la coda più velocemente del rate di produzione, segnale di un sistema che smaltisce correttamente il backlog. La tabella mostra i messaggi singoli con tutti i metadati: timestamp ISO8601, partizione (0 o 3 in questo caso), offset progressivo (77 e 100), chiave (vehicle_id: 6396, 7166) e valore JSON completo ({"vehicle_id": 6396, "engine_temperature": 243, "average_rpm": 2301}). Il grafico a barre in cima mostra il traffico minuto per minuto — utile per identificare picchi e anomalie di produzione.
La configurazione che conta: partizioni e retention
Il tab Settings mostra le configurazioni operative del topic: 6 partizioni — più del diagramma teorico a 3, per gestire un throughput reale più elevato con consumer group da 6 consumer; cleanup.policy: delete — i messaggi vengono eliminati alla scadenza del periodo di retention invece di essere compattati (l’altra policy possibile); retention.ms: 1 week — i messaggi restano disponibili per 7 giorni, dopodiché vengono rimossi automaticamente; max.message.bytes: 2097164 — circa 2 MB per messaggio, sufficiente per payload JSON ricchi anche con dati aggregati; retention.bytes: Infinite — nessun limite di spazio, il cleanup avviene solo per scadenza temporale.
Il numero di partizioni è la decisione di design più importante per le performance di Kafka: determina il parallelismo massimo sia lato produzione che lato consumo. La regola pratica: parti dal numero di consumer che prevedi di avere nel gruppo più critico — quello è il lower bound delle partizioni. Non si possono ridurre le partizioni dopo la creazione del topic (solo aumentare), quindi meglio sovrastimare con moderazione.
Perché Kafka scala dove SQL non arriva
Un database relazionale come PostgreSQL è progettato per query complesse, transazioni ACID, integrità referenziale. Queste garanzie hanno un costo: ogni scrittura deve passare per il write-ahead log, acquisire lock, aggiornare indici. A qualche migliaio di scritture al secondo, PostgreSQL inizia a faticare. Kafka è progettato per fare una sola cosa estremamente bene: append su disco sequenziale. Le scritture sequenziali sono un ordine di grandezza più veloci di quelle random — Kafka sfrutta questa caratteristica fisica dell’hardware per raggiungere throughput nell’ordine dei milioni di messaggi al secondo su hardware commodity.
Il paragone corretto non è quindi Kafka vs PostgreSQL — sono strumenti per problemi diversi. È Kafka vs code di messaggi tradizionali, dove Kafka vince grazie alla persistenza, alla riproducibilità e alla scalabilità orizzontale. Nel prossimo articolo vedremo come Kafka non si limita a trasportare i messaggi: con Kafka Streams può trasformarli in volo, aggregarli, arricchirli e connetterli ai database di destinazione tramite Kafka Connect — tutto dentro il cluster, senza codice applicativo esterno.
Prossima puntata: Kafka Parte 2 — event-driven e integrazioni
Con questa prima puntata hai i concetti base: topic, partizioni, offset, consumer group, broker. La settimana prossima entriamo nella parte operativa: Kafka Streams per le trasformazioni stateful in-flight, Kafka Connect per i connettori verso InfluxDB ed Elasticsearch, e le architetture Lambda e Kappa che usano Kafka come backbone. Il caso d’uso narrativo cambia: dal P1 Smart City al P4 Social Network Analytics Platform — dove Kafka alimenta in tempo reale sia il grafo Neo4j che il motore di ricerca Elasticsearch. Apache Kafka per lo stream processing: il sistema nervoso che tiene insieme stack dati distribuiti. Nella prossima puntata lo mettiamo in produzione.
