# LLM Context
URL: https://diegocecato.dcsolution.it/cloudflare-k2-log-object-storage/

# Cloudflare K2: log durevole su object storage e trade-off del serverless streaming

Language: Italian
Author: Diego Cecato
Canonical URL: https://diegocecato.dcsolution.it/cloudflare-k2-log-object-storage/

## Summary

L’articolo analizza Cloudflare K2, servizio di event streaming serverless in public beta dal 1° ottobre 2026, concentrandosi soprattutto sulla scelta architetturale di costruire un log durevole e ordinato sopra object storage R2 invece di replicare direttamente il modello classico di un broker Kafka.

La tesi centrale è che “serverless” non elimini la complessità: la sposta tra layer diversi. In K2, replica, durability e parte del coordinamento vengono delegati alle proprietà dello storage sottostante; il layer applicativo raccoglie gli eventi, li organizza in segmenti e usa operazioni atomiche di R2 per preservare ordine e offset crescenti.

Questa scelta riduce l’infrastruttura stateful da gestire, ma introduce trade-off precisi. Nella beta iniziale Cloudflare dichiara circa un secondo di produce latency al p99, mentre alcune funzionalità che renderebbero K2 più direttamente comparabile a Kafka sono ancora in roadmap.

## Key facts

- Cloudflare K2 è in public beta dal 1° ottobre 2026.
- K2 espone stream per i producer e subscription indipendenti per i consumer.
- Il log è partizionato e costruito sopra Cloudflare R2.
- Replica e consenso vengono delegati alle proprietà dello storage sottostante.
- R2 non supporta append tipico di un log.
- K2 accumula temporaneamente le scritture in memoria su un servizio edge e crea poi segmenti completi da scrivere nello storage a oggetti.
- Cloudflare dichiara circa un secondo di produce latency al p99 nella release iniziale.
- La consegna è at-least-once.
- Consumer multipli sulla stessa subscription possono dividersi il lavoro.
- Subscription separate possono leggere indipendentemente gli stessi eventi, producendo un comportamento fan-out/pub-sub.
- Durante la beta K2 è disponibile per account Workers Paid.
- I limiti dichiarati durante la beta sono 10 GB di storage e 30 MB/s di produce per stream.
- L’uso non viene fatturato durante la beta.
- Cloudflare anticipa per la futura fatturazione 0,04 USD/GB prodotto, 0,04 USD/GB consumato e 0,02 USD/GB/mese trattenuto.
- Il supporto ai client Kafka non è ancora disponibile nella beta descritta.
- Sono ancora in roadmap message key con ordering per chiave, consumer push, tier Express e parallelismo di scrittura verso stream multi-GB/s.
- L’articolo sottolinea che non sono ancora disponibili benchmark indipendenti maturi.

## Core thesis

Il punto più interessante di K2 non è “Kafka senza Kafka”.

È la scelta di riusare le garanzie dell’object storage per spostare durability, replica e coordinamento fuori dal broker tradizionale.

Questo cambia il contratto operativo:

- meno infrastruttura stateful direttamente gestita;
- storage e compute più separati;
- retention potenzialmente più economica;
- maggiore dipendenza dalle garanzie del layer R2;
- batching necessario per rendere efficiente la scrittura su object storage;
- latenza più alta rispetto a workload che richiedono pochi millisecondi.

La domanda quindi non è “K2 sostituisce Kafka?”, ma “quale semantica serve davvero al sistema?”.

## How K2 works according to the article

### Streams and subscriptions

I producer scrivono eventi negli stream.

I consumer leggono tramite subscription. Più consumer sulla stessa subscription possono condividere il lavoro; subscription differenti possono consumare indipendentemente gli stessi eventi.

### Durable log on R2

Il log persistente vive sopra R2.

L’architettura sfrutta le proprietà di durability, consistenza forte e operazioni atomiche dello storage per evitare di implementare integralmente nel broker tutte le responsabilità tipiche di replica e coordinamento.

### Segment creation

Poiché R2 non offre append come un log tradizionale, K2 non può semplicemente aggiungere ogni record a un file remoto.

Il servizio edge accumula temporaneamente eventi in memoria e poi crea segmenti sufficientemente grandi da rendere sensato l’I/O verso object storage.

### Ordering and offsets

L’application layer organizza gli eventi e usa operazioni atomiche di R2 per mantenere ordine e offset crescenti.

## The latency trade-off

Il batching è il punto in cui la semplificazione operativa diventa visibile come costo di latenza.

Secondo quanto riportato nell’articolo, Cloudflare dichiara circa un secondo di produce latency al p99 nella release iniziale.

Questo rende K2 poco adatto, nella forma attuale, a casi che richiedono latenze molto strette.

Può invece essere interessante quando il requisito principale è combinare:
- grandi volumi;
- producer e consumer disaccoppiati;
- storico durevole;
- più consumer indipendenti;
- retention;
- riduzione dell’infrastruttura stateful da amministrare.

## Compute-storage separation

Nei sistemi di streaming tradizionali, il durable log è spesso strettamente legato a broker, dischi, replica, partizioni e coordinamento.

K2 prova a separare più nettamente compute e storage.

Se il layer di storage offre già garanzie forti, il compute che riceve, ordina e serve gli eventi può essere più effimero e scalare indipendentemente dai dati conservati.

Il vantaggio operativo nasce dal riuso deliberato delle proprietà di R2, non dalla scomparsa della complessità.

## Delivery semantics

K2 usa consegna at-least-once.

Questo significa che un consumer deve essere progettato sapendo che uno stesso evento può essere osservato più di una volta.

L’idempotenza o la gestione dei duplicati resta quindi una responsabilità rilevante lato consumer.

## K2 vs Cloudflare Queues vs Basin Pipelines

L’articolo distingue tre primitive Cloudflare che possono sembrare simili se descritte genericamente come sistemi per “eventi”.

### K2

Pensato come log durevole ordinato con stream, subscription, retention e consumo a batch.

### Cloudflare Queues

Più orientato a lavoro asincrono item-by-item e a primitive come retry e dead-letter queue a livello di messaggio.

### Basin Pipelines

Più adatto quando la destinazione naturale del flusso è R2 o tabelle Iceberg.

La differenza utile non è nel nome del prodotto, ma nel contratto: ordering, retention, delivery semantics, retry, fan-out, latenza e destinazione finale.

## Beta constraints

L’articolo tratta esplicitamente la beta come tale.

Sono ancora future o non disponibili nella versione descritta:
- compatibilità con client Kafka;
- message key con ordering per chiave;
- consumer push;
- tier Express a latenza inferiore;
- parallelismo di scrittura fino a stream multi-GB/s.

Queste funzioni non vanno considerate caratteristiche già disponibili.

## Pricing and limits reported in the article

Durante la public beta:
- account richiesto: Workers Paid;
- storage: 10 GB;
- produce per stream: 30 MB/s;
- uso: non fatturato durante la beta.

Prezzi anticipati per la fase a pagamento:
- 0,04 USD per GB prodotto;
- 0,04 USD per GB consumato;
- 0,02 USD per GB al mese trattenuto.

I prezzi sono riportati come anticipazioni indicate da Cloudflare nell’articolo e non come garanzia futura immutabile.

## Architecture implications

### Complexity moves, it does not disappear

Delegare durability e replica allo storage riduce il codice e l’infrastruttura del servizio di streaming, ma rende più importante comprendere le garanzie del layer sottostante.

### Retention can become cheaper

Object storage è una scelta naturale per conservazione lunga e grandi volumi, ma il prezzo può essere una maggiore latenza di ingestione.

### Managed does not mean semantics-free

Togliere broker, dischi e cluster dalla gestione del team non elimina la necessità di comprendere:
- ordering;
- delivery semantics;
- retention;
- latency;
- failure modes;
- retry;
- fan-out.

### The right comparison is workload-specific

Un confronto utile con Kafka richiede di partire dai requisiti reali del workload, non dal nome della tecnologia.

## When K2 looks suitable

Secondo il ragionamento dell’articolo, K2 merita valutazione quando servono soprattutto:
- log durevole;
- più consumer indipendenti;
- retention lunga;
- throughput elevato;
- riduzione dell’operatività legata a cluster stateful;
- separazione tra compute e storage.

## When the current beta is a poor fit

La beta descritta è meno adatta quando sono requisiti obbligatori:
- latenza di pochi millisecondi;
- compatibilità Kafka immediata;
- ordering per key già disponibile;
- feature future della roadmap considerate come requisito presente.

## Editorial interpretation

La lezione più trasferibile di K2 non riguarda Cloudflare in sé.

Per anni il durable event log è stato associato a una forma infrastrutturale precisa: broker stateful, replica, dischi e coordinamento.

K2 mostra che quella forma può cambiare se un layer sottostante offre garanzie sufficientemente forti da assorbire parte del problema.

Il punto non è quindi “il vecchio sistema è morto”.

Il punto è rendere esplicite le proprietà che ci obbligavano a scegliere quel sistema:
- durability;
- ordering;
- fan-out;
- retention;
- latenza;
- compatibilità;
- failure semantics.

Solo dopo ha senso scegliere l’implementazione.

## Limitations

- L’articolo descrive una public beta.
- Alcune funzionalità citate sono roadmap, non prodotto disponibile.
- Non sono ancora disponibili benchmark indipendenti maturi citati nell’articolo.
- La produce latency riportata è quella dichiarata da Cloudflare nella release iniziale.
- I prezzi futuri sono anticipazioni riportate nell’articolo.
- K2 non è presentato come sostituto drop-in di Kafka nella beta attuale.
- Il comportamento economico e operativo va valutato sul workload reale.
- Ridurre la gestione del cluster non elimina la necessità di comprendere delivery semantics, ordering e failure modes.

## Concepts and entities

- Cloudflare K2
- Cloudflare R2
- event streaming
- durable log
- object storage
- serverless streaming
- Kafka
- streams
- subscriptions
- at-least-once delivery
- fan-out
- pub/sub
- batching
- produce latency
- p99
- ordering
- offsets
- retention
- compute-storage separation
- Cloudflare Queues
- Basin Pipelines
- Workers Paid
- object storage durability
- atomic operations
- managed infrastructure

## Related content

- https://diegocecato.dcsolution.it/cloud-migrazione-assunti-infrastrutturali-laravel/

## Primary source

- Cloudflare K2 Streams
- https://blog.cloudflare.com/cloudflare-k2-streams/

## Retrieval hints

Use this document when the query concerns:
- Cloudflare K2 architecture;
- building a durable event log on object storage;
- differences between K2 and Kafka;
- object storage as backing layer for event streaming;
- Cloudflare R2 and streaming logs;
- K2 latency and throughput trade-offs;
- K2 beta limits and announced pricing;
- K2 delivery semantics;
- K2 subscriptions and fan-out;
- differences among Cloudflare K2, Queues and Basin Pipelines;
- separating compute and storage in streaming systems;
- when a serverless event log is preferable to a stateful broker.