Apache Kafka è una piattaforma open source di data streaming distribuita, sviluppata originariamente da LinkedIn e donata alla Apache Software Foundation nel 2011. È progettata per gestire flussi di dati in tempo reale ad altissimo volume: pubblicazione, sottoscrizione, memorizzazione duratura e processamento di stream di eventi tra sistemi applicativi eterogenei.

Nel 2026, con la serie 4.x completamente basata su KRaft (l'architettura interna che ha sostituito ZooKeeper), Kafka si è consolidato come il backbone di streaming de facto per le architetture event-driven enterprise e come fondazione dati in tempo reale per i sistemi AI operativi.

Kafka si basa su un modello publish-subscribe: i producer pubblicano messaggi su topic, suddivisi in partizioni distribuite tra i broker del cluster, e i consumer si iscrivono a questi topic per leggere i messaggi in modo indipendente e parallelo. I messaggi vengono conservati su disco per un periodo configurabile, il che permette a più consumer di leggerli in tempi diversi senza che il producer debba attenderne la ricezione.

Dalla versione 4.0 (marzo 2025), Kafka gestisce internamente tutti i metadati del cluster tramite KRaft — il proprio protocollo di consenso basato su Raft — eliminando la dipendenza da ZooKeeper. Questo semplifica l'architettura operativa, riduce i componenti da gestire e abbassa il tempo di failover del controller da 18-30 secondi a meno di 5 secondi.

I vantaggi principali di Kafka sono: throughput elevatissimo (milioni di messaggi al secondo), latenza bassa, durabilità garantita dei dati su disco, scalabilità orizzontale aggiungendo broker al cluster e tolleranza ai guasti attraverso la replicazione delle partizioni. I consumer possono rileggere i dati storici riposizionando il proprio offset, il che lo rende adatto sia per elaborazione in tempo reale che per riprocessamento.

Con KRaft, dal 2025 si aggiungono vantaggi operativi rilevanti: architettura a singolo sistema (niente più ZooKeeper da gestire separatamente), failover più rapido del controller, supporto a milioni di partizioni per cluster — superando il precedente limite pratico di circa 200.000 partizioni imposto dai vincoli di memoria di ZooKeeper. Grazie al tiered storage, i segmenti più vecchi possono essere scaricati su object storage (S3, HDFS) riducendo i costi dei broker.

ZooKeeper è stato per anni il sistema esterno che Kafka usava per gestire i metadati del cluster — quali broker sono attivi, dove si trovano le partizioni, chi è il controller. Questo significava operare due sistemi distribuiti separati, con complessità, monitoring e patching distinti.

KRaft (Kafka Raft) incorpora il consenso e la gestione dei metadati direttamente nei broker Kafka, usando il protocollo Raft. Con Kafka 4.0, ZooKeeper non è stato deprecato ma definitivamente rimosso: ogni nuovo cluster gira esclusivamente in modalità KRaft. I benefici pratici sono: un solo sistema da operare invece di due, failover del controller in meno di 5 secondi, supporto a milioni di partizioni e deployment più semplice su Kubernetes — con meno StatefulSet, PersistentVolumeClaim e configurazioni di rete da gestire.

I modelli AI e gli agenti intelligenti hanno bisogno di dati aggiornati in tempo reale per prendere decisioni contestuali accurate. Kafka risolve questo problema fornendo il canale attraverso cui eventi aziendali — transazioni, log di sistema, interazioni utente, telemetria IoT — vengono resi disponibili in streaming ai sistemi AI nel momento in cui avvengono, senza batch e senza delay.

Kafka funziona come backbone per le architetture RAG in tempo reale (Retrieval-Augmented Generation), per i sistemi AIOps che analizzano log e metriche infrastrutturali su stream continui, e per le pipeline di inferenza che devono reagire a eventi esterni. La combinazione Kafka + Apache Flink — quest'ultimo diventato lo standard per il processamento degli stream in ambienti enterprise — permette di trasformare, filtrare e arricchire i dati in volo prima che raggiungano i modelli AI o i sistemi decisionali.

I sistemi di messaggistica tradizionali (RabbitMQ, ActiveMQ) sono progettati per la consegna di messaggi a singoli consumer: una volta letto il messaggio, viene rimosso dalla coda. Kafka invece è un log distribuito immutabile: i messaggi vengono conservati per un periodo configurabile e più consumer indipendenti possono leggerli in tempi diversi, ciascuno con il proprio offset, senza interferire tra loro. Questo abilita casi d'uso impossibili con le code tradizionali: audit trail completo degli eventi, riprocessamento storico, alimentazione simultanea di sistemi multipli dallo stesso stream.

Con Kafka 4.1 è entrata in early access la funzionalità Queues for Kafka (KIP-932), che aggiunge semantiche point-to-point classiche ai topic Kafka attraverso il modello share-group: più consumer all'interno dello stesso gruppo possono leggere dalla stessa partizione con acknowledgment per singolo messaggio. Questo estende Kafka anche ai casi d'uso in cui un sistema di code tradizionale era preferito, senza dover mantenere due infrastrutture separate.