Cos'è Kafka e come viene usato nei sistemi moderni?

Kafka in parole semplici

Apache Kafka è una piattaforma distribuita di event streaming. In termini semplici, è una “tubo” condiviso e durevole che permette a molti sistemi di pubblicare fatti su ciò che è successo e ad altri sistemi di leggere quei fatti—velocemente, a scala e in ordine.

I team usano Kafka quando i dati devono muoversi in modo affidabile tra sistemi senza un forte accoppiamento. Invece di far sì che un'applicazione chiami direttamente un'altra (e fallisca se è giù o lenta), i producer scrivono eventi in Kafka. I consumer li leggono quando sono pronti. Kafka conserva gli eventi per un periodo configurabile, così i sistemi possono riprendersi da interruzioni e persino riprocessare la storia.

Alcuni termini che vedrai

• Evento / Messaggio: Una registrazione di qualcosa che è accaduto (ad esempio, “OrderPlaced” o “PaymentFailed”). Chi usa Kafka spesso dice “messaggio”, ma “evento” sottolinea che rappresenta un cambiamento reale.
• Stream: Un flusso continuo di eventi nel tempo.
• Log: Kafka organizza gli eventi come un log append-only—i nuovi eventi vengono aggiunti alla fine e i lettori avanzano al proprio ritmo.

A chi è rivolto questa guida (e cosa imparerai)

Questa guida è per ingegneri orientati al prodotto, persone dei dati e leader tecnici che vogliono un modello mentale pratico di Kafka.

Imparerai i blocchi fondamentali (producer, consumer, topic, broker), come Kafka scala con le partizioni, come memorizza e riproduce gli eventi e dove si inserisce nell'architettura event-driven. Copriremo anche casi d'uso comuni, garanzie di consegna, nozioni di sicurezza, pianificazione operativa e quando Kafka è (o non è) lo strumento giusto.

Concetti core: Producer, Consumer, Topic, Broker

Kafka è più semplice da capire come un log di eventi condiviso: le applicazioni scrivono eventi su di esso e altre applicazioni leggono quegli eventi dopo—spesso in tempo reale, a volte ore o giorni dopo.

Producer e consumer

Producer sono gli scrittori. Un producer potrebbe pubblicare un evento come “order placed”, “payment confirmed” o “temperature reading”. I producer non inviano eventi direttamente ad app specifiche—invece li inviano a Kafka.

Consumer sono i lettori. Un consumer potrebbe alimentare una dashboard, attivare un workflow di spedizione o caricare dati per analytics. I consumer decidono cosa fare con gli eventi e possono leggerli al proprio ritmo.

Topic: organizzare gli eventi

Gli eventi in Kafka sono raggruppati in topic, che sono fondamentalmente categorie nominate. Per esempio:

• orders per eventi legati agli ordini
• payments per eventi di pagamento
• inventory per variazioni di stock

Un topic diventa lo stream “source of truth” per quel tipo di evento, facilitando il riuso dei dati da parte di più team senza integrare soluzioni ad hoc.

Broker e cluster

Un broker è un server Kafka che memorizza eventi e li serve ai consumer. In pratica, Kafka gira come un cluster (più broker che lavorano insieme) così può gestire più traffico e rimanere operativo anche se una macchina fallisce.

Consumer group: scalare i lettori senza duplicare il lavoro

I consumer spesso girano in un consumer group. Kafka suddivide il lavoro di lettura tra i membri del gruppo, così puoi aggiungere istanze consumer per scalare il processing—senza che ogni istanza esegua lo stesso lavoro.

Come topic e partizioni fanno scalare Kafka

Kafka scala dividendo il lavoro in topic (stream di eventi correlati) e poi spezzando ogni topic in partizioni (fette più piccole e indipendenti di quello stream).

Partizioni = parallelismo e throughput

Un topic con una sola partizione può essere letto da un solo consumer alla volta all'interno di un consumer group. Aggiungi più partizioni e puoi aggiungere più consumer per processare gli eventi in parallelo. È così che Kafka supporta l'event streaming ad alto volume e le pipeline di dati in tempo reale senza trasformare ogni sistema in un collo di bottiglia.

Le partizioni aiutano anche a distribuire il carico tra i broker. Invece che una sola macchina gestisca tutte le scritture e letture per un topic, più broker possono ospitare partizioni diverse e condividere il traffico.

Ordinamento: cosa Kafka garantisce (e cosa no)

Kafka garantisce l'ordinamento all'interno di una singola partizione. Se gli eventi A, B e C vengono scritti nella stessa partizione in quell'ordine, i consumer li leggeranno A → B → C.

L'ordinamento tra partizioni non è garantito. Se hai bisogno di un ordinamento rigoroso per una specifica entità (come un cliente o un ordine), di solito fai in modo che tutti gli eventi per quell'entità vadano nella stessa partizione.

Le chiavi decidono dove vanno gli eventi

Quando i producer inviano un evento, possono includere una key (ad esempio order_id). Kafka usa la key per instradare in modo coerente eventi correlati nella stessa partizione. Questo dà un ordinamento prevedibile per quella key pur permettendo al topic di scalare su molte partizioni.

Replica per mantenere i dati disponibili

Ogni partizione può essere replicata su altri broker. Se un broker fallisce, un altro broker con una replica può subentrare. La replica è una delle ragioni principali per cui Kafka è affidabile in sistemi critici: migliora la disponibilità e supporta la tolleranza ai guasti senza costringere ogni applicazione a implementare logiche di failover.

Storage, retention e replay degli eventi

Un'idea chiave in Apache Kafka è che gli eventi non vengono solo passati e dimenticati. Vengono scritti su disco in un log ordinato, così i consumer possono leggerli ora—o dopo. Questo rende Kafka utile non solo per muovere dati, ma anche per mantenere una storia durevole di ciò che è successo.

Eventi persistenti, non solo “in transito”

Quando un producer invia un evento a un topic, Kafka lo appende allo storage sul broker. I consumer leggono poi da quel log memorizzato al proprio ritmo. Se un consumer è giù per un'ora, gli eventi esistono ancora e possono essere recuperati al suo riavvio.

Retention: per quanto Kafka conserva i dati

Kafka conserva gli eventi secondo policy di retention:

• Retention basata sul tempo: conserva gli eventi per un periodo stabilito (per esempio 7 giorni).
• Retention basata sulla dimensione: conserva finché il log non raggiunge una dimensione configurata, poi elimina i dati più vecchi.

La retention si configura per topic, così puoi trattare in modo diverso i topic di audit da quelli di telemetria ad alto volume.

Compattazione: mantenere il valore più recente per chiave

Alcuni topic sono più simili a un changelog che a un archivio storico—per esempio, “impostazioni utente correnti”. La log compaction mantiene almeno l'evento più recente per ogni chiave, mentre i record più vecchi possono essere rimossi. In questo modo ottieni una fonte di verità duratura per lo stato più recente senza crescita illimitata.

Replay degli eventi: ricostruire stato e recuperare dai bug

Poiché gli eventi rimangono memorizzati, puoi riprodurli per ricostruire lo stato:

• Ricostruire un indice di ricerca o una view materializzata da zero
• Recuperare un servizio dopo un deploy errato riprocessando da un punto precedente
• Onboardare un nuovo consumer lasciandolo leggere dati storici

Nella pratica, il replay è controllato da dove un consumer “inizia a leggere” (il suo offset), dando ai team una rete di sicurezza potente quando i sistemi evolvono.

Affidabilità e basi della tolleranza ai guasti

Kafka è progettato per mantenere il flusso di dati anche quando parti del sistema falliscono. Lo fa con replica, regole chiare su chi è “responsabile” di ogni partizione e acknowledgment di scrittura configurabili.

Replica: leader e follower (livello alto)

Ogni partizione ha un broker leader e uno o più replica follower su altri broker. Producer e consumer parlano con il leader di quella partizione.

I follower copiano continuamente i dati del leader. Se il leader va giù, Kafka può promuovere un follower aggiornato a nuovo leader, così la partizione rimane disponibile.

Cosa succede durante un fallimento di broker (breve)

Se un broker fallisce, le partizioni per cui era leader diventano temporaneamente non disponibili. Il controller di Kafka rileva il problema e avvia l'election del leader per quelle partizioni.

Se almeno una replica è sufficientemente aggiornata, può prendere il posto del leader e i client riprendono a produrre/consumare. Se non ci sono repliche in-sync, Kafka potrebbe mettere in pausa le scritture (a seconda delle impostazioni) per evitare la perdita di dati già confermati.

Durabilità: replication factor e acknowledgments

Due principali leve influenzano la durabilità:

• Replication factor: quante copie di ogni partizione esistono (ad esempio 3 copie su 3 broker).
• Acknowledgments (acks): quando il producer considera una scrittura riuscita.

A livello concettuale:

• acks=0: il producer non aspetta—veloce, ma puoi perdere messaggi.
• acks=1: il leader conferma la scrittura—meglio, ma se il leader fallisce prima che i follower copino i dati, puoi perdere messaggi recenti.
• acks=all (o -1): il leader aspetta le repliche “in sync” per confermare—più sicuro, generalmente un po' più lento.

Per ridurre duplicati durante i retry, i team spesso combinano acks più sicuri con producer idempotenti e una gestione robusta dei consumer.

Trade-off tra latenza e sicurezza

Maggiore sicurezza tipicamente significa aspettare più conferme e mantenere più repliche in sync, il che può aggiungere latenza e ridurre il throughput massimo.

Impostazioni a bassa latenza possono andar bene per telemetria o clickstream dove la perdita occasionale è accettabile, ma pagamenti, inventario e log di audit solitamente giustificano la maggiore sicurezza.

Il ruolo di Kafka nell'architettura event-driven

L'architettura event-driven (EDA) è un modo di costruire sistemi in cui gli eventi di business—un ordine effettuato, un pagamento confermato, un pacco spedito—sono rappresentati come eventi a cui altre parti del sistema possono reagire.

Pubblica eventi, reagisci con i consumer

Kafka spesso sta al centro di EDA come lo “stream di eventi” condiviso. Invece che il Servizio A chiami il Servizio B direttamente, il Servizio A pubblica un evento (ad esempio OrderCreated) su un topic Kafka. Un numero qualsiasi di servizi può consumare quell'evento e agire—inviare un'email, riservare inventario, avviare controlli antifrode—senza che il produttore debba conoscerli.

Disaccoppiamento (meno dipendenze dirette)

Poiché i servizi comunicano tramite eventi, non devono coordinare API request/response per ogni interazione. Questo riduce dipendenze strette tra team e rende più facile aggiungere nuove funzionalità: puoi introdurre un nuovo consumer per un evento esistente senza cambiare il producer.

Workflow asincroni e resistenza agli spike

EDA è naturalmente asincrona: i producer scrivono eventi rapidamente e i consumer li processano al proprio ritmo. Durante picchi di traffico, Kafka aiuta a smorzare l'ondata così i sistemi downstream non crollano immediatamente. I consumer possono scalare per recuperare, e se un consumer va giù temporaneamente può riprendere da dove aveva lasciato.

Un modello mentale pratico

Pensa a Kafka come al “feed di attività” del sistema. I producer pubblicano fatti; i consumer si iscrivono ai fatti che gli interessano. Questo pattern abilita pipeline di dati in tempo reale e workflow event-driven mantenendo i servizi più semplici e indipendenti.

Casi d'uso comuni di Kafka nei sistemi moderni

Kafka tende a comparire dove i team devono muovere molti piccoli “fatti che sono accaduti” (eventi) tra sistemi—velocemente, in modo affidabile e in modo che più consumer possano riutilizzare gli stessi dati.

Tracciamento attività e log di audit

Le applicazioni spesso hanno bisogno di una storia append-only: accessi utente, cambi di permessi, aggiornamenti di record o azioni amministrative. Kafka funziona bene come stream centrale di questi eventi, così strumenti di sicurezza, report e esportazioni per compliance possono leggere la stessa fonte senza gravare sul DB di produzione. Poiché gli eventi sono trattenuti per un periodo, puoi anche riprodurli per ricostruire una vista di audit dopo un bug o un cambiamento di schema.

Comunicazione tra microservizi via eventi

Invece di chiamate dirette, i servizi possono pubblicare eventi come “order created” o “payment received”. Altri servizi si iscrivono e reagiscono a loro tempo. Questo riduce l'accoppiamento, aiuta i sistemi a restare operativi durante outage parziali e facilita l'aggiunta di nuove capacità (ad esempio controlli antifrode) semplicemente consumando lo stream esistente.

Pipeline di dati verso analytics e warehouse

Kafka è una spina dorsale comune per spostare dati dai sistemi operazionali verso piattaforme analitiche. I team possono streamare cambiamenti dai database applicativi e portarli in un warehouse o data lake con bassa latenza, mantenendo l'app di produzione separata dalle query analitiche pesanti.

IoT e telemetria con traffico bursty

Sensori, dispositivi e telemetria app arrivano spesso a raffica. Kafka può assorbire gli spike, bufferizzarli in sicurezza e permettere al processing downstream di recuperare—utile per monitoring, alerting e analisi a lungo termine.

Ecosistema Kafka: Connect, Streams e strumenti

Kafka è più dei broker e dei topic. La maggior parte dei team si affida a strumenti complementari che rendono Kafka pratico per il movimento quotidiano dei dati, il processing degli stream e le operazioni.

Kafka Connect: muovere dati senza codice custom

Kafka Connect è il framework di integrazione di Kafka per portare dati in Kafka (source) e fuori Kafka (sink). Invece di costruire e mantenere pipeline one-off, esegui Connect e configuri i connector.

Esempi comuni includono estrarre cambiamenti dai database, ingerire eventi SaaS o consegnare dati Kafka a un data warehouse o object storage. Connect standardizza anche preoccupazioni operative come retry, offset e parallelismo.

Kafka Streams: elaborazione in tempo reale nelle tue app

Se Connect è per l'integrazione, Kafka Streams è per il calcolo. È una libreria che aggiungi alla tua applicazione per trasformare stream in tempo reale—filtrare eventi, arricchirli, unire stream e costruire aggregati (come “ordini al minuto”).

Poiché le app Streams leggono da topic e scrivono su topic, si integrano naturalmente in sistemi event-driven e possono scalare aggiungendo istanze.

Gestione degli schemi: mantenere gli eventi coerenti

Quando più team pubblicano eventi, la coerenza conta. La gestione degli schemi (spesso tramite uno schema registry) definisce quali campi un evento dovrebbe avere e come evolvono nel tempo. Questo aiuta a prevenire rotture come la rinominazione di un campo usato da un consumer.

Strumenti: monitorare ciò che conta

Kafka è sensibile dal punto di vista operativo, quindi il monitoraggio di base è essenziale:

• Consumer lag: i consumer stanno rimanendo indietro?
• Throughput: quanti eventi al secondo fluiscono?
• Errori: fetch falliti, errori di produce, task connector che falliscono

La maggior parte dei team usa anche UI di gestione e automazioni per deploy, configurazione dei topic e policy di accesso.

Garanzie di consegna e pattern di elaborazione

Kafka è spesso descritto come “log duraturo + consumer”, ma ciò che interessa davvero alla maggior parte dei team è: processerò ogni evento una volta e cosa succede quando qualcosa fallisce? Kafka offre i mattoni di base e tu scegli i compromessi.

Garanzie di consegna (livello alto)

At-most-once significa che potresti perdere eventi, ma non processerai duplicati. Succede se un consumer commette la posizione prima di completare il lavoro e poi si blocca.

At-least-once significa che non perderai eventi, ma i duplicati sono possibili (ad esempio, il consumer processa un evento, poi crasha e lo rielabora al restart). Questo è il comportamento più comune.

Exactly-once mira a evitare sia perdita che duplicati end-to-end. In Kafka ciò coinvolge tipicamente producer transazionali e processing compatibile (spesso con Kafka Streams). È potente, ma più vincolante e richiede una configurazione attenta.

Idempotenza e deduplicazione

Nella pratica molti sistemi accettano at-least-once e aggiungono salvaguardie:

• Scritture idempotenti: rendi l'applicazione dello “evento” sicura da ripetere (es. upsert, update condizionali, chiavi uniche).
• Deduplicazione: conserva un ID evento (o chiave di business) e ignora ripetizioni entro una finestra.

Offset dei consumer: il tuo “segnalibro”

Un offset consumer è la posizione dell'ultimo record processato in una partizione. Quando commetti offset, dici “ho finito fino a qui”. Commit troppo presto e rischi perdita; troppo tardi e aumenti i duplicati dopo un fallimento.

Retry e messaggi velenosi

I retry dovrebbero essere limitati e visibili. Un pattern comune è:

1. retry con backoff per errori transitori,
2. poi inviare il record fallito a un dead-letter topic per ispezione e replay.

Questo evita che un singolo “poison message” blocchi un intero consumer group mantenendo i dati disponibili per correzioni future.

Sicurezza e governance

Kafka spesso trasporta eventi business-critical (ordini, pagamenti, attività utente). Questo rende sicurezza e governance parte del design, non un ripensamento.

Autenticazione e autorizzazione

L'autenticazione risponde a “chi sei?” L'autorizzazione risponde a “cosa puoi fare?” In Kafka, l'autenticazione è comunemente fatta con SASL (ad es. SCRAM o Kerberos), mentre l'autorizzazione è applicata con ACL a livello di topic, consumer group e cluster.

Un pattern pratico è least privilege: i producer possono scrivere solo sui topic di loro pertinenza e i consumer possono leggere solo ciò di cui hanno bisogno. Questo riduce l'esposizione accidentale dei dati e limita l'impatto se le credenziali vengono compromesse.

Crittografia in transito (TLS)

TLS cripta i dati mentre si muovono tra app, broker e strumenti. Senza TLS, gli eventi possono essere intercettati anche su reti interne. TLS aiuta anche a prevenire attacchi man-in-the-middle validando l'identità dei broker.

Kafka multi-tenant e convenzioni di naming

Quando più team condividono un cluster, servono guardrail. Convenzioni chiare per i nomi dei topic (ad esempio <team>.<dominio>.<evento>.<versione>) rendono evidente la proprietà e aiutano gli strumenti ad applicare policy in modo coerente.

Abbina naming a quote e template di ACL così un carico rumoroso non prosciuga gli altri e i nuovi servizi partono con impostazioni sicure.

Data governance: PII, retention e allineamento

Tratta Kafka come sistema di record per la storia degli eventi solo se intendi farlo. Se gli eventi includono PII, usa minimizzazione dati (invia ID invece di profili completi), considera la crittografia a livello di campo e documenta quali topic sono sensibili.

Le impostazioni di retention dovrebbero rispecchiare requisiti legali e aziendali. Se la policy dice “elimina dopo 30 giorni”, non conservare 6 mesi “nel caso”. Revisioni e audit regolari mantengono le configurazioni allineate con l'evoluzione dei sistemi.

Gestire Kafka: cosa pianificare

Gestire Apache Kafka non è “installalo e dimenticalo”. Si comporta come un servizio condiviso: molti team dipendono da esso e piccoli errori possono propagarsi alle app downstream.

Basi di capacity planning

La capacità di Kafka è soprattutto un problema di matematica da rivedere regolarmente. Le leve principali sono partizioni (parallelismo), throughput (MB/s in ingresso e in uscita) e crescita dello storage (quanto a lungo conservi i dati).

Se il traffico raddoppia, potresti aver bisogno di più partizioni per distribuire il carico tra i broker, più disco per la retention e più banda per la replica. Un'abitudine pratica è prevedere il tasso di scrittura di picco e moltiplicarlo per la retention per stimare la crescita del disco, poi aggiungere un buffer per replica e “successo inaspettato”.

Compiti operativi quotidiani

Aspettati lavoro routinario oltre a mantenere i server in piedi:

• Upgrade: pianifica rolling upgrade, testa compatibilità client e schedula le modifiche nei momenti di minor traffico.
• Rebalancing: i rebalance dei consumer group possono causare pause brevi; serve pattern di deploy sicuri e responsabilità chiare.
• Incident response: playbook per fallimenti di broker, disco pieno e producer mal configurati che floodano un topic.

Driver di costo e scelte di deployment

I costi sono guidati da dischi, egress di rete e dal numero/dimensione dei broker. Kafka gestito può ridurre il carico operativo e semplificare gli upgrade, mentre l'auto-gestione può essere più economica a scala se hai operatori esperti. Il trade-off è tempo di recupero e on-call.

Cosa misurare (per non andare a occhio)

I team tipicamente monitorano:

• Latenza end-to-end (produce → consume)
• Consumer lag (quanto i consumer sono indietro)
• Salute dei broker (uso disco, partizioni under-replicated, errori di richiesta)

Buone dashboard e alert trasformano Kafka da “scatola nera” a servizio comprensibile.

Quando usare Kafka (e quando no)

Kafka è adatto quando devi muovere molti eventi in modo affidabile, conservarli per un periodo e permettere a più sistemi di reagire agli stessi dati al proprio ritmo. È particolarmente utile quando i dati devono essere riproducibili (backfill, audit, ricostruzione di servizi) e quando prevedi di aggiungere producer/consumer nel tempo.

Quando Kafka è una scelta eccellente

Kafka brilla quando hai:

• Stream ad alto throughput (click, ordini, dati da sensori)
• Molti consumer che hanno bisogno degli stessi eventi (analytics, monitoring, antifrode, notifiche)
• Bisogno di replay e storia duratura, non solo “consegna e dimentica”
• Lavoro di integrazione dove disaccoppiare team e servizi è importante

Quando Kafka può essere eccessivo

Kafka può essere sovradimensionato se i tuoi bisogni sono semplici:

• Una singola coda a basso volume tra due servizi
• Task short-lived (job in background) dove il replay non serve
• Team senza tempo per operare e monitorare un sistema distribuito

In questi casi l'overhead operativo (sizing del cluster, upgrade, monitoraggio, on-call) può superare i benefici.

Alternative e complementi

• RabbitMQ: ottimo per code di lavoro classiche e pattern di routing.
• NATS: messaggistica leggera con bassa latenza.
• Cloud pub/sub: utile se vuoi infrastruttura gestita e operazioni più semplici.

Kafka completa—non sostituisce—database (system of record), cache (letture veloci) e strumenti di ETL batch (trasformazioni periodiche su larga scala).

Checklist rapida per decidere

Chiediti:

1. Abbiamo bisogno di più consumer e di replay?
2. Il throughput crescerà significativamente?
3. Abbiamo bisogno di history/retention come funzionalità?
4. Possiamo supportare la proprietà operativa (o usare Kafka gestito)?
5. Stiamo streamando eventi e non solo inviando comandi/task?

Se rispondi “sì” a gran parte di queste, Kafka è di solito una scelta sensata.

Primo approccio: percorso di adozione semplice

Kafka funziona meglio quando serve una “fonte di verità” condivisa per stream di eventi in tempo reale: molti sistemi che producono fatti (ordini creati, pagamenti autorizzati, inventario modificato) e molti sistemi che consumano quei fatti per pipeline, analytics e funzionalità reattive.

Passo 1: scegli un caso d'uso concreto

Inizia con un flusso ristretto e ad alto valore—come pubblicare eventi “OrderPlaced” per servizi downstream (email, antifrode, fulfillment). Evita di trasformare Kafka in una coda universale dal giorno zero.

Passo 2: definisci eventi e topic

Annota:

• Eventi: cosa è successo, in termini di business
• Topic: dove vivono quegli eventi (spesso un topic per tipo di evento o dominio)
• Consumer: quali team/servizi hanno bisogno degli eventi e perché

Mantieni gli schemi iniziali semplici e coerenti (timestamp, ID e un nome evento chiaro). Decidi se imporre schemi subito o evolverli con cautela.

Passo 3: stabilisci responsabilità e basi operative

Kafka ha successo quando qualcuno possiede:

• Creazione topic e convenzioni di naming
• Policy di retention e accesso
• Responsabilità on-call e runbook

Aggiungi subito monitoring (consumer lag, salute broker, throughput, errori). Se non hai ancora un team piattaforma, parti con un'offerta gestita e limiti chiari.

Passo 4: costruisci una pipeline “sottile” iniziale

Produci eventi da un sistema, consumali in un posto, e dimostra il loop end-to-end. Solo dopo espandi a più consumer, partizioni e integrazioni.

Se vuoi muoverti velocemente dall'idea a un servizio event-driven funzionante, strumenti come Koder.ai possono aiutarti a prototipare l'app circostante rapidamente (UI React, backend Go, PostgreSQL) e aggiungere producer/consumer Kafka tramite un flusso di lavoro guidato in chat. È particolarmente utile per costruire dashboard interne e servizi leggeri che consumano topic, con funzionalità come modalità di pianificazione, esportazione del codice sorgente, deploy/hosting e snapshot con rollback.

Se stai mappando questo in un approccio event-driven, vedi il post sul blog sull'architettura event-driven. Per pianificare costi e ambienti, consulta la pagina dei prezzi.