iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Cloudflare K2 is the company’s serverless event-streaming service, now in public beta, that stores durable, ordered event logs on R2 object storage. Its central tradeoff is latency: Cloudflare reports about one second of produce latency at the 99th percentile in the initial release. That number comes from Cloudflare’s own announcement dated October 1, 2026. It is not an independent benchmark and not a service guarantee.
What K2 is
K2 is a service for producing events to a durable log and then reading them back through subscriptions. Producers write over a Workers binding or over HTTP. Consumers track their position in the log, pull batches, and acknowledge them after processing. Cloudflare’s K2 product page says retention can be configured up to one month.
In the announcement, Cloudflare’s authors, Micah Wylde and Marc Selwan, describe the design in one sentence: “Under the hood, K2 implements a partitioned, durable log on top of R2 object storage, which allows it to scale to huge volumes of storage.”
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsWhy K2 is built on object storage
A conventional log broker appends records to files on local disks. Object stores such as R2 do not offer an append operation, so K2 cannot write one record at a time to a growing file. Instead, it works in batches:
#1 Best Overall
- Writes accumulate in memory at an edge service.
- When a batch is ready, it is written to object storage as a complete segment file.
- Ordering and strictly increasing offsets come from R2 atomic operations. Cloudflare says this removes the need for a separate coordination service.
K2 began as a durable edge buffer for Basin Pipelines, Cloudflare’s pull-based stream-processing engine. Its job was to decouple producers from consumers so each consumer could process at its own pace. Cloudflare says its edge runs in more than 335 cities, on small and relatively ephemeral machine slices, with networking that often crosses the public Internet. In that environment, Cloudflare judged its existing R2 storage primitive a better base than operating a conventional Kafka cluster for this workload.
Where the latency comes from
The delay is structural. A produce request does not return until the batch containing it has been committed to object storage. The R2 architecture documentation, last updated April 21, 2026, describes the general write path for an R2 object:
- An edge gateway receives the write.
- Encryption and routing are applied.
- The data is written to distributed storage and replicated across regions.
- A metadata commit records the object.
- R2 returns HTTP 200 only after that metadata commit.
These are properties of R2 in general. K2 adds its own step on top, waiting for a local batch to fill before the segment is written, and that wait is the main reason its produce latency is higher than local disk writes. The latency figure below describes the combined result, not R2 alone.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →What the one-second figure does and does not tell you
In the initial release, Cloudflare says the batching design “adds up to about 1 second of produce latency at the 99th percentile of response times.” Read that sentence with these limits in mind:
- Source: It is Cloudflare’s figure, published October 1, 2026. The sources reviewed for this article contain no independent measurement, test protocol, or third-party validation.
- Percentile: It describes the 99th percentile. It says nothing about the median or the slowest one percent.
- Scope: It should not be extended to every region, payload size, workload, or future pricing tier. Cloudflare has not published conditions for those variables in the material reviewed.
- Not a guarantee: It describes what Cloudflare observed for the initial release. It is not a service-level commitment.
Cloudflare also cites 11 nines of durability for R2 object storage. That is the company’s stated figure, not an independently audited finding. Cloudflare has said a deeper technical write-up of K2’s design would follow, so check for it if you need implementation detail beyond the announcement.
K2, Queues, or Basin Pipelines
Cloudflare positions three products for different shapes of work. The table summarizes its guidance and the limits the company states. Where Cloudflare did not state a value, the cell says so.
| Option | Best fit (per Cloudflare) | Unit of work | Retry behavior | Produce latency | Retention and fan-out |
|---|---|---|---|---|---|
| K2 | High-scale data movement, long-term retention, fan-out, custom processing, or destinations other than object storage and Iceberg | Batches of records in an ordered log | Consumers lease batches; failed work or an expired lease is redelivered (at-least-once) | About 1 second at p99 in the initial release (Cloudflare figure) | Retention configurable up to one month; multiple subscriptions for fan-out |
| Queues | Individual expensive or time-consuming work items | Individual messages | Item-level retries, delays, and dead-letter queues | Higher than K2 by Cloudflare’s comparison; no figure stated | Not stated in the Cloudflare sources reviewed |
| Basin Pipelines | Destination is object storage or Iceberg tables | Not stated in the Cloudflare sources reviewed | Not stated in the Cloudflare sources reviewed | Not stated in the Cloudflare sources reviewed | Not stated in the Cloudflare sources reviewed |
The practical consequence is that K2 gives up per-message retry granularity in exchange for efficient batch processing and fan-out. If one failed item should not hold up or re-run a whole batch, Cloudflare’s guidance points to Queues instead.
How consumers read and recover
K2’s delivery model is at-least-once, so a consumer can see the same event more than once. The read cycle works like this:
- Create a subscription. It tracks the consumer’s position in the log.
- Choose a pattern. Share one subscription among several consumers to split work, or create several subscriptions so each one receives every event for fan-out.
- Lease a batch. The consumer receives a batch under a time-limited lease.
- Process and acknowledge. Acknowledge the batch after processing succeeds.
- Recover from failure. If processing fails or the lease expires before acknowledgment, the batch is delivered again.
Because of redelivery, consumer code should be idempotent, meaning that handling the same event twice produces the same result as handling it once. This follows directly from the at-least-once model.
Who should evaluate K2
- A good fit: high-volume event streams that need retention of up to a month, multiple independent consumers, or custom processing that does not fit an object-storage or Iceberg destination.
- Consider Queues instead: each work item is expensive and needs its own retry and dead-letter handling.
- Consider Basin Pipelines instead: the destination is object storage or Iceberg tables.
- Test first: if your producers cannot tolerate roughly one second of p99 write delay, measure K2 against your own payloads and regions before committing.
K2 is in public beta, and its limits, retention options, and pricing can change. Check Cloudflare’s K2 product page for current values before you design around them.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
