Kafka: fundamentals and architecture

Questa lezione prosegue il binario ml-tabellare del modulo: qui impari a leggere l’architettura di Kafka come una mappa di decisioni — chiavi, conferme di scrittura e retention — che determinano durabilità, ordine e costo dei tuoi dati.

L’idea in una frase

L’architettura di Kafka è un log partizionato e replicato dove chiavi, conferme di scrittura e retention decidono durabilità, ordine e costo.

La procedura in cinque passi

1. Scegli la chiave di partizionamento in base all’ordine che devi garantire.
2. Fissa fattore di replica e ISR minime in base alla perdita che tolleri.
3. Scegli il livello di acks dichiarando il compromesso tra durabilità e latenza.
4. Fissa la retention in base al valore del replay: 7 giorni come standard, di più per audit.
5. Dimensiona partizioni e broker sui volumi reali, con test di carico prima del rilascio.

Perché l’architettura conta

Un broker Kafka non è una coda generica. Topic, partizioni, consumer group e retention definiscono come l’organizzazione pubblica gli eventi, li conserva e li rilegge. Il punto non è accumulare definizioni: è capire quale decisione di disegno cambia quando scegli una configurazione invece di un’altra. Se sbagli la chiave di partizionamento, il problema non resta tecnico. Diventa ordine rotto, consumer sbilanciati e analisi a valle che non tornano.

Il problema vero non è conoscere Kafka in astratto, ma disegnare i topic con vincoli reali: volumi che crescono, consumer che restano indietro, formati che devono restare compatibili nel tempo. Leggi l’architettura come mappa delle responsabilità. Chi produce, chi consuma, chi possiede il topic, quanto dura la retention e cosa succede quando un consumer accumula ritardo. Le basi servono quando ti permettono di prevedere il comportamento sotto carico, prima della produzione.

Da qui in avanti collega ogni concetto a una scelta concreta: come partizionare, quale garanzia chiedere alla scrittura, quanta retention tenere. Se una nozione non cambia una di queste decisioni, è solo terminologia.

Replication and fault tolerance

Ogni partizione ha un leader e N follower, configurati con replication.factor. Il leader gestisce tutte le letture e scritture, mentre i follower replicano passivamente. Se un broker muore, uno dei follower viene eletto leader.

Le ISR (In-Sync Replicas) sono le repliche allineate al leader, cioè con un lag inferiore a replica.lag.time.max.ms (default 30s). Solo una ISR può essere eletta leader. Se imposti min.insync.replicas=2, almeno due broker devono confermare una scrittura prima che sia considerata committed. Questo protegge dalla perdita di dati quando un broker muore subito dopo aver ricevuto una scrittura.

Delivery guarantees: acks

Il producer sceglie il livello di garanzia con il parametro acks:

• acks=0: fuoco e dimentica, nessuna garanzia, throughput massimo.
• acks=1: conferma il solo leader. Se il leader muore prima che i follower replichino, i dati vanno persi.
• acks=all (o -1): confermano tutte le ISR, nessuna perdita di dati, latenza più alta.

Per l’analytics, acks=1 è spesso sufficiente, perché un evento perso ogni tanto non sposta le metriche. Per le transazioni finanziarie serve invece acks=all. La scelta rende esplicita la soglia di rischio: stai dichiarando quanta perdita tolleri in cambio di latenza.

Idempotency and transactions

Il producer idempotente, con idempotenza attiva, garantisce che un messaggio inviato più volte per via dei retry venga scritto una sola volta. Kafka assegna un identificativo di producer e un numero di sequenza a ogni messaggio, e il broker deduplica.

Le transazioni permettono di scrivere in modo atomico su più topic o partizioni: o tutti i messaggi sono committed, o nessuno lo è. Sono il meccanismo che abilita la semantica exactly-once in Kafka Streams.

Cluster sizing

Tre numeri guidano il dimensionamento. Le partizioni non devono scendere sotto il throughput target diviso 10 MB/s, perché una singola partizione regge circa 10-20 MB/s in scrittura: per 1 GB/s servono circa 100 partizioni. La retention bilancia costo di storage e valore analitico: 7 giorni è lo standard, mentre per audit e compliance si sale a 30-90 giorni. Sul fronte broker, il minimo per la fault tolerance è 3, e ogni broker regge circa 1-2 Gbps di throughput con hardware standard.

Esempio: la decisione di partizionamento

Il caso tipico è un team che progetta i topic per ordini, pagamenti e spedizioni. La scelta critica è se partizionare per order_id, customer_id o area geografica, perché da qui dipendono ordine degli eventi, parallelismo dei consumer e facilità di ricostruzione storica. La tabella seguente mostra come leggere alcuni segnali tipici prima di decidere.

Situation	Cautious interpretation	Decision
Il throughput migliora ma su una baseline debole	Il guadagno potrebbe dipendere dal campione di carico	Rafforzare il test prima di scalare le partizioni
Una sola partizione riceve la maggior parte del traffico	La chiave scelta crea hotspot	Rivedere la chiave o aumentare la cardinalità
Il costo operativo cresce con le partizioni	Più partizioni significano più overhead di coordinamento	Fissare una soglia economica esplicita
I consumer producono conteggi incoerenti	L’ordine per chiave non è garantito come previsto	Correggere ownership del topic e contratto degli eventi

Errori tipici da evitare

L’errore più frequente è trattare l’architettura come un’etichetta invece che come criterio di scelta. Succede quando presenti un numero senza dire quale decisione cambia, quale baseline lo rende interpretabile e quale rischio resta aperto. In quel caso il dato sembra preciso, ma non guida l’azione.

Ce ne sono altri tre da tenere d’occhio. Il primo è lavorare su dati aggregati troppo presto: una media globale può nascondere due segmenti che si muovono in direzioni opposte. Il secondo è non controllare la qualità del dato, perché eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. Il terzo è confondere correlazione e causalità: se gli utenti che usano una feature convertono di più, non significa che la feature causi conversione, potrebbero usarla perché erano già più motivati. Per ridurre questi rischi tieni sempre una definizione esplicita della metrica, un confronto per segmento e una verifica contro un periodo precedente.

L’esempio che fa da riferimento

Kafka nasce in LinkedIn per unificare la raccolta dei log e viene descritto nel 2011 da Kreps, Narkhede e Rao nel paper presentato a NetDB. Il disegno di log partizionato e replicato con leader, follower e ISR viene da quell’esigenza operativa. Nel 2015 Jun Rao ha documentato la semantica exactly-once in arrivo sulla piattaforma, chiudendo il triangolo tra replicazione, conferme di scrittura e transazioni. Da quel percorso discendono le scelte della lezione: chiavi, conferme, repliche e retention sono decisioni di durabilità, non parametri.

Verdetto: per l’analytics acks=1 è spesso sufficiente, per le transazioni finanziarie serve acks=all: la scelta della chiave, delle conferme e della retention dichiara quanta perdita tolleri in cambio di latenza, e se una nozione non cambia una di queste decisioni è solo terminologia.

Domande per verificare la lezione

1. Quale chiave di partizionamento hai scelto e quale ordine garantisce?
2. Quale fattore di replica e quante ISR minime proteggono le tue scritture?
3. Quale livello di acks usi e quanta perdita tolleri in cambio di latenza?
4. Quanta retention tieni e quale replay ti permette dopo un errore a valle?