Kafka senza Kafka? Cloudflare K2 sposta il log nello storage a oggetti

La notizia facile è che Cloudflare ha lanciato K2, un servizio di event streaming serverless. Quella interessante è un’altra: per costruire un log durevole e ordinato, Cloudflare ha deciso di spostare una parte del lavoro che normalmente associamo ai broker verso lo storage a oggetti.

K2 è in public beta dal 1° ottobre 2026. Espone stream a cui i producer inviano eventi e subscription da cui i consumer li leggono in modo indipendente. Sotto, però, non c’è un cluster Kafka mascherato: Cloudflare descrive un log partizionato costruito sopra R2. Replica e consenso vengono delegati alle proprietà dello storage; l’application layer accumula gli eventi, li organizza in segmenti e usa operazioni atomiche di R2 per mantenere ordine e offset crescenti.

È una scelta architetturale più interessante del prodotto in sé, perché mostra bene cosa significa davvero “serverless”: non eliminare la complessità, ma decidere in quale layer farla vivere.

Kafka senza Kafka è uno slogan. Il trade-off è la sostanza

Chiamare K2 “Kafka serverless” aiuta a orientarsi, ma rischia di nascondere la parte importante. K2 oggi non è un sostituto drop-in di Kafka: il supporto ai client Kafka è nella roadmap, così come le message key con ordering per chiave e un tier a latenza più bassa. La beta attuale ha un contratto diverso e, soprattutto, paga un prezzo preciso per l’architettura scelta.

R2 non supporta l’append tipico di un log. K2 quindi raccoglie temporaneamente le scritture in memoria su un servizio edge e poi crea segmenti completi abbastanza grandi da rendere sensato l’I/O verso object storage. Questo semplifica la gestione della durability, ma introduce attesa. Cloudflare dichiara circa un secondo di produce latency al p99 nella release iniziale.

Quando sposti la complessità da un layer a un altro non l’hai eliminata. Hai cambiato il contratto che devi capire, misurare e accettare.

Se il requisito è una pipeline a latenza strettissima, quel secondo non è un dettaglio. Se invece devi assorbire grandi volumi, disaccoppiare producer e consumer, mantenere uno storico e permettere a più lettori di procedere al proprio ritmo, il compromesso può diventare molto interessante. È qui che il confronto corretto smette di essere “K2 contro Kafka” e diventa “quale semantica serve davvero a questo sistema?”.

Separare compute e storage cambia l’economia operativa

Nei sistemi di streaming tradizionali il log durevole è strettamente legato all’infrastruttura che lo serve: broker, dischi, replica, partizioni, coordinamento, failover. Le implementazioni managed tolgono già molto lavoro dalle mani del team, ma il modello resta riconoscibile.

K2 prova una strada diversa. Se lo storage sottostante offre già durability elevata, consistenza forte e operazioni atomiche, una parte delle responsabilità può scendere di livello. Il compute che riceve e organizza gli eventi può così essere più effimero e scalare separatamente dai dati conservati. Non è magia: è un riuso deliberato delle garanzie di R2.

È lo stesso tipo di ragionamento che rende insidiose molte migrazioni verso servizi managed: il codice applicativo cambia magari poco, ma cambiano gli assunti infrastrutturali. Qui l’assunto da mettere nero su bianco è che durability e coordinamento non sono più proprietà del broker locale; diventano parte del contratto con lo storage e con il servizio che gli sta sopra.

Il modello di consumo conta più del nome del servizio

K2 conserva gli eventi come un log ordinato e li espone attraverso subscription. Più consumer sulla stessa subscription possono dividersi il lavoro; subscription separate possono invece leggere indipendentemente gli stessi eventi, ottenendo un comportamento da fan-out/pub-sub. La consegna è at-least-once: quindi il consumer deve comunque essere progettato sapendo che un evento può essere visto più di una volta.

Questo lo distingue da Cloudflare Queues, che è orientato al lavoro asincrono item-by-item e offre meccanismi come retry e dead-letter queue a livello di messaggio. K2 ragiona invece per flussi, retention e consumo a batch. Basin Pipelines ha ancora un altro contratto: è indicato quando il percorso naturale dei dati termina in R2 o in tabelle Iceberg.

Tre primitive che possono apparire sovrapposte se ci si ferma alla parola “eventi”, ma che risolvono problemi diversi. È un promemoria utile anche fuori da Cloudflare: scegliere un componente perché “fa streaming” o “fa code” è troppo poco. Bisogna guardare almeno ordering, retention, delivery semantics, modello di retry, fan-out, latenza e destinazione finale.

La beta mette già dei numeri sul tavolo

Durante la public beta K2 è disponibile per account con Workers Paid. I limiti dichiarati sono 10 GB di storage e 30 MB/s di produce per stream; l’uso non viene fatturato nel periodo beta. Cloudflare anticipa, per quando partirà la fatturazione, 0,04 dollari per GB prodotto, 0,04 per GB consumato e 0,02 per GB al mese trattenuto.

Questi numeri sono utili, ma non bastano per trasformare K2 in una risposta universale. Mancano ancora benchmark indipendenti maturi, il deep dive tecnico promesso da Cloudflare non è ancora disponibile e alcune funzioni che renderebbero il confronto con Kafka più diretto sono esplicitamente future: parallelismo di scrittura fino a stream multi-GB/s, ordering per key, consumer push, tier Express e compatibilità con client Kafka.

In altre parole: oggi si può valutare l’architettura e sperimentare il contratto. Non ha senso trattare la roadmap come se fosse già prodotto.

La lezione più utile non riguarda Cloudflare

Per anni abbiamo associato il durable event log a una certa forma infrastrutturale: broker stateful, dischi, replica e coordinamento. K2 mostra che quella forma non è obbligatoria se un layer sottostante offre garanzie abbastanza forti da assorbire parte del problema.

Ma il vantaggio arriva insieme a un nuovo profilo di compromessi. Object storage rende economica la retention e permette di separare compute e dati; il batching necessario per trasformarlo in un log aumenta la latenza. Delegare replica e consenso riduce il codice e l’infrastruttura del servizio; allo stesso tempo aumenta l’importanza delle garanzie offerte dal layer sottostante. Togliere il cluster dalle mani del team riduce l’operatività, non la necessità di capire la semantica.

L’architettura migliora quando smettiamo di chiedere quale tecnologia sostituisce Kafka e iniziamo a chiedere quale problema ci obbligava a usare Kafka.

Se la risposta è “mi serve un log durevole, molti consumer indipendenti e retention lunga, ma non mi serve una latenza di pochi millisecondi”, K2 merita un test. Se la risposta include compatibilità Kafka immediata, ordering per key già disponibile o latenze strette, la beta attuale dice chiaramente di aspettare o scegliere altro.

Ed è probabilmente il risultato migliore che può produrre una nuova primitive infrastrutturale: non convincerci che il vecchio sistema sia morto, ma costringerci a esplicitare quali proprietà ci servono davvero.