Introduction to streaming with Kafka

Questa lezione apre il modulo e appartiene al binario ml-tabellare: la stessa disciplina che applichi a una tabella di dati — definire la metrica, dichiarare la baseline, verificare prima di decidere — vale identica quando i dati arrivano come un flusso continuo di eventi.

L’idea in una frase

Kafka è un log condiviso e rileggibile che sostituisce le integrazioni punto a punto quando volume, riuso e replay ripagano l’esercizio.

La procedura in cinque passi

1. Misura volume reale, numero di consumer e bisogno di replay prima di scegliere.
2. Definisci topic, chiave di ordinamento e owner di ogni flusso.
3. Fissa retention e formato degli eventi come interfacce esplicite.
4. Scarta Kafka dove bastano code semplici o batch: la latenza deve servire a una decisione.
5. Collega ogni consumer a una scelta concreta che i suoi dati migliorano.

Perché lo streaming cambia il problema

Il business non aspetta la mezzanotte per reagire. Ordini, click, pagamenti e log arrivano mentre le decisioni sono già in corso, e la domanda vera è come trasportarli senza imbastire un’integrazione fragile per ogni coppia di sistemi. La risposta di Kafka è un modello preciso: gli eventi confluiscono in un log condiviso, ordinato per chiave e riutilizzabile. Spariscono le connessioni punto a punto che si rompono al primo cambiamento.

Con i batch notturni l’azienda lavora su una fotografia vecchia di ore. Lo streaming non rende più veloce lo stesso lavoro: abilita decisioni diverse. Un antifrode che vede la transazione mentre avviene può bloccarla; lo stesso sistema, se la vede il giorno dopo, può solo scrivere un report.

Conviene distinguere tre piani: l’evento, cioè il fatto accaduto; l’infrastruttura che lo trasporta e lo conserva; la decisione che quei dati devono migliorare. Kafka è utile quando riduce l’accoppiamento tra sistemi, rende i dati riusabili e conserva abbastanza storia da correggere un errore a posteriori. Diventa costoso quando lo si sceglie solo perché il tempo reale suona meglio del batch, senza che alcuna decisione richieda davvero quella latenza.

Fundamental Concepts

A topic è un flusso logico di messaggi, paragonabile a una tabella in un database: user-events, orders, page-views. Un’azienda può averne centinaia.

Ogni topic è diviso in partizioni per scalare orizzontalmente. Ogni partizione è un log immutabile e ordinato. I messaggi nella stessa partizione mantengono l’ordine, mentre l’ordine globale tra partizioni diverse non è garantito. È il primo punto che chi arriva da un database tende a sottovalutare.

Theoffset è la posizione di un messaggio dentro la partizione: un intero crescente. Ogni consumer tiene traccia dell’offset per sapere fin dove ha letto. Il producer scrive su Kafka e decide la partizione di ogni messaggio, di default tramite l’hash della chiave. Il consumer legge da Kafka dentro un consumer group: ogni partizione è assegnata a un solo consumer del gruppo, così ogni messaggio è processato una volta per gruppo. Il broker è un singolo server Kafka, e un cluster ne usa più di uno per tolleranza ai guasti e throughput.

Il log immutabile

Qui sta la differenza rispetto a una coda tradizionale come RabbitMQ, dove un messaggio sparisce appena viene consumato. Kafka conserva i messaggi per un periodo configurabile, di default sette giorni ma potenzialmente all’infinito. Così passa da sistema di messaggistica a event store.

Le conseguenze sono pratiche. Puoi rileggere i messaggi dall’inizio e riprocessare lo storico quando scopri un bug a valle. Più consumer group leggono gli stessi dati in modo indipendente, senza interferire tra loro. E un nuovo consumer può partire da zero e recuperare tutta la storia. È l’event sourcing: il log di Kafka è la fonte di verità, e ogni sistema a valle deriva il proprio stato leggendolo.

Quando Kafka serve e quando no

Kafka ha senso per flussi ad alto throughput, indicativamente sopra i 10.000 messaggi al secondo, per microservizi da tenere disaccoppiati, per event sourcing, change data capture e analytics in tempo reale. Sotto questa soglia il rapporto tra valore e complessità operativa cambia segno.

Kafka non serve, invece, per code di task semplici, dove RabbitMQ o SQS bastano e costano meno; per volumi bassi, sotto il centinaio di messaggi al secondo, dove l’overhead di gestione non si ripaga; e per applicazioni che richiedono transazioni ACID, dove un database resta la scelta giusta. Scegliere Kafka per inerzia, perché lo usano tutti, è il modo più comune di pagarne la disciplina operativa senza riceverne i benefici.

Come impostare la scelta

La domanda prima di introdurre uno streaming backbone non è “quale metrica calcolo” ma “quale decisione dovrà migliorare grazie a questo”. Un’integrazione, una dashboard o un consumer group hanno valore solo se riducono l’incertezza di una scelta concreta. Se non cambiano alcuna decisione, sono documentazione o teatro tecnico.

Conviene anche dichiarare l’unità di lavoro (topic, evento, schema, producer, consumer o stream processor), il segnale osservato (latenza, throughput, lag, compatibilità schema, perdita dati), la baseline di lettura e la decisione attesa, che sia un contratto evento, una pipeline o una policy operativa. Il rischio costante è scambiare un numero disponibile per una prova sufficiente.

Un team che valuta se sostituire export schedulati e webhook fragili con un backbone a eventi deve pesare volume reale, fan-out verso i consumer, necessità di replay, ordine per chiave e competenze operative disponibili. Uno streaming system risolve integrazioni complesse, ma chiede in cambio una disciplina nuova: chi possiede i topic, come si gestiscono gli schemi, come si misura il lag.

Errori comuni

Il primo errore è lavorare su dati aggregati troppo presto, perché una media globale può coprire due segmenti che vanno in direzioni opposte. Il secondo è non controllare la qualità del dato: eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false con facilità sorprendente. Il terzo è confondere correlazione e causalità: se gli utenti che usano una feature convertono di più, non significa che la feature causi la conversione; potrebbero usarla proprio perché erano già più motivati.

Per ridurre questi rischi, tieni in ogni analisi tre controlli minimi: una definizione esplicita della metrica, un confronto per segmento e una verifica contro un periodo precedente o un gruppo di controllo.

Verdetto: adotta Kafka sopra soglie di throughput e fan-out che ripagano l’esercizio, resta su code semplici o batch dove latenza e replay non decidono nulla.

References:

• Kreps, J., Narkhede, N. e Rao, J. (2011). “Kafka: a Distributed Messaging System for Log Processing.” NetDB 2011.
• Confluent. (2024). “Apache Kafka Documentation.” kafka.apache.org/documentation.

L’esempio che fa da riferimento

Kafka nasce in LinkedIn per sostituire una rete fragile di pipeline punto a punto con un log centrale condiviso tra decine di sistemi. Il paper di Kreps, Narkhede e Rao del 2011 descrive quel passaggio: eventi ordinati per partizione, conservati nel tempo e rileggibili da consumer indipendenti. Da quell’esperienza deriva il modello della lezione: topic come interfacce, log immutabile come fonte di verità, consumer group indipendenti. La distinzione tra code che cancellano e log che conservano resta il criterio per decidere quando Kafka serve davvero.

Domande per verificare la lezione

1. Quale decisione diventa possibile in streaming che in batch notturno arriva tardi?
2. Quale volume e quanti consumer indipendenti giustificano Kafka nel tuo caso?
3. Quale chiave mantiene l’ordine dove l’ordine è necessario?
4. Quando una coda semplice o un database restano scelte migliori di Kafka?