Cloudflare K2: serverless event streams
Cloudflare launched K2, a serverless event streaming service built on R2 object storage for high-scale data movement and long-term retention.
summary is enough The announcement describes a standard event streaming primitive; the technical implementation details are high-level and the value is primarily for Cloudflare ecosystem users.
summary
Cloudflare K2 is a durable, partitioned event log that decouples producers and consumers by using R2 object storage as its substrate. It is designed for high-throughput data movement and fan-out consumption rather than individual task tracking. Because it batches writes to object storage, it has higher produce latency (p99 ~1s) but offers significantly lower costs for long-term data retention compared to disk-based systems like Kafka.
key points
- Implements a durable log on top of R2 object storage, separating compute from storage to allow independent scaling.
- Produces events in batches to overcome the lack of object store append operations, resulting in ~1 second p99 produce latency.
- Supports both work-splitting (parallel consumers) and pub/sub (all consumers see all messages) patterns.
- Pricing is based on data volume ($0.04/GB produced, $0.04/GB consumed, $0.02/GB/month retained) rather than per-message.
who should read it
Developers already using Cloudflare Workers who need a scalable, cost-effective event stream for analytics or data pipelines.
discussion positive
consensus
Commenters generally view the 'object-store first' architecture as a growing trend for building scalable, stateless systems. There is agreement that K2 is a cost-effective alternative to Kafka for users who can tolerate higher latency.
pushback
Some users expressed concern over the high cost of data consumption for fan-out patterns and the lack of portability due to the proprietary API.
Sure! There are definitely some overlapping use cases, and we've seen folks using/abusing queues for use cases that are more appropriate to something like k2.
Queues are great when you have a unit of work that needs to be completed, retried, and tracked individually. For example, a shop might need to call a payment processor API that can fail or timeout, and retry it until it succeeds, while polling on the frontend for the state of that particular message. With a queue, you can insert a message tracking that payment, and have a queue processor that keeps getting sent it until it succeeds or …
The author of the post clarifies the specific distinction between K2 and Cloudflare Queues, explaining that Queues are for individual work items with retries, while K2 is for bulk data movement.
Generated by an LLM from the article and thread. Check the sources before relying on it.