Per anni, architetti e sviluppatori hanno adottato Apache Kafka come standard per l’event streaming e i log distribuiti, continuando però ad affidarsi a sistemi come RabbitMQ per il queuing tradizionale.
Questa separazione non è mai stata ideologica, bensì architetturale. Nel modello classico dei consumer group di Kafka, esiste infatti un vincolo fondamentale: la mappatura 1:1 tra partizione e consumer attivo.
Se un topic ha tre partizioni, ad esempio, è possibile scalare fino a un massimo di tre consumer per consumare i messaggi in modalità cooperativa. Un quarto rimarrà inattivo. Questo modello garantisce ordinamento parziale e gestione efficiente degli offset, ma introduce un limite strutturale alla concorrenza e alla flessibilità operativa.
Con KIP-932, introdotto in preview in Apache Kafka 4.0 e rilasciato definitivamente in Apache Kafka 4.2, questo paradigma cambia radicalmente. Nascono gli Share Groups, un modello che porta il concetto di queue nativamente dentro Kafka, permettendo il disaccoppiamento tra il processamento dei messaggi e lo storage e superando alcuni dei limiti storici del log distribuito così come pensato in origine in Kafka.
I Limiti del Modello di Consumo Convenzionale
Per comprendere il valore degli Share Groups, è necessario analizzare le criticità del modello classico basato sui Consumer Group di Kafka.
Il Massimo Livello di Parallelismo
Nel modello basato sui Kafka Consumer Group, la massima parallelizzazione nel consumo di messaggi è limitata dal numero di partizioni. Questo può portare alla necessità di utilizzare tecniche di over-partitioning preventivo: le aziende creano topic con centinaia di partizioni solo per assorbire i picchi di carico (ad esempio il picco di utenti o ordini durante il Black Friday), mantenendo un’infrastruttura sovradimensionata per il resto dell’anno.
Head of Line (HOL) Blocking
Un singolo consumer all’interno di un Consumer Group ha assegnato un’intera partizione e i messaggi vengono elaborati in ordine sequenziale.
Se un singolo messaggio richiede una chiamata verso un sistema esterno lento, esegue un task computazionalmente pesante, oppure fallisce ripetutamente, l’intera partizione rimane bloccata. Questo fenomeno è noto come Head of Line (HOL) blocking.
Il risultato è una pipeline che si ferma a causa di un singolo evento problematico.
Il costo del Rebalancing
Il rebalancing è il meccanismo di fault tolerance di Kafka. Tuttavia, soprattutto nelle versioni meno recenti, poteva diventare un evento altamente invasivo: durante la riassegnazione delle partizioni, il consumo si interrompeva, aumentando la latenza e generando instabilità nei momenti di picco. Le versioni più recenti di Kafka hanno introdotto alcune ottimizzazioni, ma non hanno comunque eliminato il problema.
Kafka Share Groups: Assegnamento a Livello di Record
L’innovazione del KIP-932 risiede nel passaggio dalla logica “un consumer per partizione” a quella “più consumer cooperano sulla stessa partizione”.
Non è più la partizione a essere assegnata in modo esclusivo, ma i singoli record (o batch di record). Questo consente di scalare il numero di consumer oltre il numero di partizioni, eliminando il vincolo storico della concorrenza.
Come Funziona: Lo Share-Partition Leader
In questa nuova architettura, la gestione dello stato non è più legata a un semplice offset sequenziale. Viene introdotta la figura dello Share-Partition Leader, co-locata con il leader della partizione fisica. Il suo compito è gestire lo stato dei cosiddetti In-Flight Records, ovvero i messaggi attualmente in fase di elaborazione.
Per mantenere alte le performance, Kafka utilizza una “finestra mobile” definita da due nuovi marcatori:
- SPSO (Share-Partition Start Offset): L’offset del primo messaggio non ancora confermato (acknowledged).
- SPEO (Share-Partition End Offset): Il limite superiore dei messaggi disponibili per essere prelevati dallo Share Group.
Questo approccio permette a Kafka di gestire topic enormi senza dover mantenere in memoria lo stato di ogni singolo record dell’intera storia del topic.
Il Ciclo di Vita del Record e la Resilienza
Con la KIP-932, ogni record ha associato uno stato che evolve secondo una macchina a stati:
- Available: Il record è nel log e pronto per essere consumato.
- Acquired: Il record è stato inviato a un consumer e “bloccato” per un tempo definito (lock duration).
- Acknowledged: Il consumer conferma l’elaborazione con successo.
- Archived: Se un record fallisce ripetutamente o il tempo di lock scade troppe volte viene archiviato automaticamente.
Questa logica integra nativamente la gestione dei Poisonous Messages, impedendo che un singolo record errato blocchi il sistema indefinitamente e migliorando la robustezza complessiva dell’applicazione.e application.
Rebalancing Senza Interruzioni
A differenza dei Consumer Groups classici, il rebalancing negli Share Groups è molto meno invasivo. Poiché i record non sono “posseduti” esclusivamente tramite l’assegnamento della partizione, l’aggiunta o la rimozione di un consumer non richiede lo stop completo del processamento: il sistema continua semplicemente a distribuire i record disponibili ai membri attivi.
Quando usare gli Share Group
Nonostante i vantaggi evidenti in termini di scalabilità e flessibilità, l’adozione degli Share Group richiede una valutazione attenta di alcuni compromessi architettonici fondamentali. Il primo e più evidente è la perdita dell’ordinamento parziale. Con gli Share Group, i record possono essere processati fuori sequenza a causa della concorrenza intrinseca di più consumer o dei meccanismi di retry. Se la logica applicativa dipende rigorosamente dalla sequenzialità dei messaggi per partizione, questo modello non è la scelta corretta.
Un altro limite significativo riguarda l’ottimizzazione dei costi di rete: attualmente non è supportato il Follower Fetching. Lo stato dei lock (“Acquired”) risiede esclusivamente nella memoria dello Share-Partition Leader. Replicare questo stato transitorio in tempo reale sui follower è una sfida complessa che, per ora, impedisce l’uso del “Rack Aware Fetching”. In ambienti multi-zona, ciò può comportare costi di rete superiori rispetto al modello tradizionale.
Infine, bisogna considerare l’assenza del supporto Exactly Once Semantic (EOS). Sebbene sia possibile leggere record scritti transazionalmente, il protocollo attuale non include la possibilità di confermare la consegna dei messaggi all’interno di una transazione atomica. Se l’applicazione richiede garanzie transazionali rigide end-to-end, il consumer group classico rimane lo standard di riferimento.
A livello pratico esistono comunque alcuni scenari dove questa tecnologia può fare la differenza:
- Task a Lunga Durata: dispatching di task complessi, come trasformazioni dati pesanti su singoli eventi, senza rischiare di stallare altri messaggi a causa di partizioni bloccate.
- Ottimizzazione dei Costi Cloud: su piattaforme come Confluent Cloud, le partizioni hanno un peso economico. Con gli Share Groups, possiamo scalare il calcolo (consumer) indipendentemente dallo storage (partizioni), reggendo picchi di messaggi senza dover sovradimensionare l’intera infrastruttura Kafka
Conclusione
L’introduzione degli Share Groups con il KIP-932 segna il superamento dello storico confine tra streaming e queuing in Apache Kafka. Questa evoluzione permette alle aziende di disaccoppiare finalmente la potenza di calcolo dallo storage, eliminando colli di bottiglia critici come l’Head of Line blocking e ottimizzando i costi infrastrutturali legati all’over-partitioning.
Tuttavia, l’adozione di questo modello richiede un’analisi strategica dei trade-off, specialmente per quanto riguarda la perdita dell’ordinamento e l’assenza di semantiche Exactly-Once. È qui che l’expertise di Bitrock diventa determinante: non ci limitiamo all’implementazione tecnica, ma guidiamo le aziende in una trasformazione digitale end-to-end. Grazie alla nostra profonda conoscenza dell’ecosistema Kafka, aiutiamo i partner a bilanciare innovazione e solidità architetturale garantendo ai nostri clienti di ottenere un vantaggio competitivo concreto e sostenibile.
Vuoi scoprire come gli Share Groups possono ottimizzare la tua architettura? Contattaci per una consulenza tecnica dedicata.
Autore: Simone Esposito, Software Architect & Team Lead @ Bitrock