Cloudflare K2: Serverless Event Streaming auf R2 mit rund einer Sekunde Produce-Latenz
Cloudflare hat K2 als öffentliche Beta gestartet, einen serverlosen Event-Streaming-Dienst mit durable Log auf R2 Object Storage. Cloudflare gibt eine Produce-Latenz von etwa einer Sekunde bei p99 an, ein externer Tester maß im End-to-End-Vergleich allerdings deutlich höhere Werte.
Der Dienst begann als Infrastruktur-Grundlage. Basin Pipelines brauchte einen dauerhaften Ort, um Events zwischenzuspeichern, bevor seine Pull-basierte Verarbeitungs-Engine sie auslas und transformierte. Die meisten Unternehmen greifen an dieser Stelle zu Apache Kafka. Cloudflare konnte das nicht. Pipelines laufen über einen Edge mit mehr als 335 Städten, auf kleinen Schnipseln kurzlebiger Maschinen, vernetzt über das öffentliche Internet, und Kafka setzt keines davon voraus.
Also bauten sie auf dem auf, was Durability bereits beherrscht. R2 bietet elf Neunen mit stark konsistenten APIs. Verschiebt man Replikation und Konsens in die Storage-Schicht, wird die darüberliegende Anwendungsschicht einfacher, und Compute und Storage skalieren getrennt.
Object Stores können nicht anhängen, was unpraktisch ist, wenn die gesamte Abstraktion ein Log ist. K2 umgeht das, indem es Schreibvorgänge im Speicher eines Edge-Dienstes hält, kurz innehält, um weitere eintreffen zu lassen, und den Batch dann als Segmentdatei wegschreibt. R2s atomare Operationen liefern die Ordnung und die inkrementierenden Offsets, sodass es überhaupt keinen Koordinationsdienst gibt. Diese Pause ist die Latenz.
Die Reaktion auf Hacker News war gegenüber dem Muster überwiegend positiv und gegenüber den Zahlen aufmerksam.
Der Kommentator psanford umriss die größere Verschiebung:
Der Object Store wird schnell zum neuen Kern-Substrat für Daten. Bauen wir Kafka, aber auf S3. Bauen wir GitHub, aber auf S3.
Der Kommentator necubi, der sich im Thread als Autor des Beitrags und Tech Lead von K2 zu erkennen gab, stimmte zu, dass sich jedes Datenmodell, das keine Latenz unter 100ms erfordert, in Richtung Object Storage bewegt, und wies darauf hin, dass sein Team neben dem R2-Team sitzt und die Produkte gemeinsam weiterentwickeln kann. Der Beitrag wird Micah Wylde und Marc Selwan zugeschrieben.
Der schärfste Austausch kam von jemandem, der die Beta betreibt. Der Kommentator e1g berichtete von Schreibvorgängen unter einer Sekunde, aber einer End-to-End-Zustellungslatenz von p95 2,5 Sekunden und p99 7,5 Sekunden, und fragte, ob das erwartet wurde. Ein Kommentator, der für das Team antwortete, erklärte, die Tail-Latenz liege höher als erwartet, die Consume-API habe bei der Performance noch Arbeit vor sich, und Verbesserungen der Leselatenz sollten innerhalb von etwa einer Woche sichtbar werden.
Ein Wettbewerber hielt den Gegenpunkt. Der Kommentator sensodine, der offenlegte, im selben Umfeld an s2.dev zu arbeiten, argumentierte, die Gelegenheit reiche auch unter 100ms, und verwies auf schnellere Object-Storage-Tiers wie S3 Express und GCS Rapid Buckets, die beide zonal sind und daher für regionale Dauerhaftigkeit dennoch Quorum-Writes erfordern. Er beschrieb den zugrunde liegenden Konflikt:
Einer der Konflikte ist natürlich, wie lange man wartet, bevor man in den Object Storage flushes. Man tauscht direkt zwischen Latenz und den Kosten der API-Operationen für PUTs.
Sein eigener Dienst, sagte er, nutzt zustandsbehaftete Backend-Prozesse, die mehrstufige Mandanten-Objekte mit Datensätzen aus vielen Streams kontinuierlich flushen und damit aus derselben Region etwa 50ms p99 Bestätigungslatenz erreichen, ohne die Unit Economics zu ruinieren.
Die Preisgestaltung zog den anderen substanziellen Einwand nach sich. Der Kommentator nnx hielt vier Cent pro GB für erzeugte Daten im Vergleich zu anderen Cloud-Event-Streams für vernünftig, fand aber den identischen Preis für den Konsum steil:
Das bedeutet, dass die tatsächliche Nutzung im einfachsten Fall (ein Konsument) 0,08 Dollar pro GB beträgt, aber Fan-out-Konsumenten-Strategien werden sehr schnell sehr teuer.
Das ist relevant, weil Fan-out einer der Anwendungsfälle ist, für die Cloudflare K2 positioniert. Die Aufbewahrung wird separat mit 0,02 Dollar pro GB pro Monat berechnet, und während der Beta wird nichts abgerechnet.
Derselbe Kommentator verteidigte den Kosten-Nutzen gegen die naheliegenden Alternativen und sagte, K2s Vorteil gegenüber Google Pub/Sub seien die Kosten, insbesondere bei längerer Aufbewahrung, und dass Object Storage es deutlich günstiger mache als selbst gehostetes oder in der Cloud gehostetes Kafka wie Amazon MSK oder Confluent, ohne Cluster zu verwalten und mit konsistenter Performance bei wachsendem Datenvolumen. Er stellte den Kompromiss im selben Kommentar erneut dar und bezifferte Produce- und End-to-End-Latenz auf etwa 1s p99 gegenüber Systemen, die auf lokale Festplatten-Replikation setzen.
Mehrere Kommentatoren fragten, wie sich K2 von AutoMQ und WarpStream unterscheidet, die dasselbe Object-Storage-Muster anwenden, und wiesen darauf hin, dass Kafka selbst inzwischen diskless Topic-Unterstützung bietet. Eine Antwort kam von einem anderen Kommentator statt von Cloudflare: Es ist für das Cloudflare-Ökosystem gebaut, und eine eigenständige Nutzung ergibt nicht viel Sinn.
Kafka-Kompatibilität steht auf der Roadmap, und der K2-Tech Lead war offen, warum:
Ich persönlich bin kein großer Fan der Kafka-API. Ich denke, sie ist gleichzeitig zu niedrig für normale Nutzer und zu hoch, um sich tief in andere Systeme zu integrieren (wie Stream-Processing-Engines), und erfordert eine komplexe Client-Bibliothek, um sie effektiv zu nutzen.
K2 verwendet stattdessen eine lease-basierte Consume-API, bei der ein Konsument ein Subscription pollt, einen Batch erhält, der für fünf Minuten geleast ist, und diesen dann bestätigt, negativ bestätigt (für erneute Zustellung) oder den Lease verlängert. Er sagte, dieses Design ermögliche eine höhere Lese-Parallelität, was wichtig ist, wenn Konsumenten Workers sind, die gut parallelisieren, aber einzeln nicht besonders leistungsstark sind.
Auf der Produktionsseite sendet ein Worker-Binding Batches und zeigt an, ob sich ein Fehler zum Wiederholen lohnt:
const result = await env.EVENTS.send([ { content: new TextEncoder().encode( JSON.stringify({ event: "page_view", path: new URL(request.url).pathname, timestamp: Date.now(), }), ), headers: { "content-type": "application/json" }, }, ]); if (!result.success) { console.error(`Produce failed: ${result.error.message}`); return new Response("Failed to record event", { status: result.error.retryable? 503: 500, }); } K2 repräsentiert Daten als Bytes und überlässt die Kodierung der Anwendung.
Wenn diese Reaktionen repräsentativ sind, geht es bei den Fragen darum, wo die Latenzuntergrenze liegt, nicht darum, ob die Architektur Sinn ergibt. Cloudflare veröffentlicht eine Zahl von einer Sekunde für Produce, ein Nutzer hat die End-to-End-Tail-Latenz mehrfach darüber gemessen, und ein Wettbewerber behauptet 50ms in einer Same-Region-Konfiguration mit zustandsbehaftetem Flushing statt reinem Object Storage.
Die Beta-Grenzen liegen bei 10GB Storage und 30 MB/s Produce pro Stream, mit einem Formular für Erhöhungen. Message-Keys und key-basierte Ordnung, Schreib-Parallelität im Multi-Gigabyte-pro-Sekunde-Bereich, push-basierte Worker-Consumer, eine Latenzärmere Express-Tier und Kafka-Client-Unterstützung sind allesamt als künftige Arbeiten aufgeführt. Streams werden über das Dashboard, die API, Wrangler oder cf erstellt, das Kommandozeilen-Interface, das Cloudflare in derselben Woche eingeführt hat.
15.–16. Dezember 2026. Erfahren Sie, wie erfahrene Praktiker Agents, Evals, Model Serving und KI-unterstützte Technik im Produktivbetrieb einsetzen, einschließlich dessen, was scheiterte und was sich änderte. Jetzt registrieren.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
The service started as plumbing. Basin Pipelines needed somewhere durable to park events before its pull-based processing engine read and transformed them. Most companies reach for Apache Kafka at that point. Cloudflare couldn't. Pipelines run across an edge of more than 335 cities, on small slices of ephemeral machines, networked over the public internet, and Kafka assumes none of that.
So they built on the thing that already handles durability. R2 gives eleven nines with strongly consistent APIs. Push replication and consensus down into the storage layer and the application layer above it gets simpler, with compute and storage scaling apart.
Object stores cannot append, which is awkward when the whole abstraction is a log. K2 gets around it by holding writes in memory on an edge service, pausing for a moment to let more arrive, then writing the batch out as a segment file. R2's atomic operations supply the ordering and the incrementing offsets, so there is no coordination service at all. That pause is the latency.
Reaction on Hacker News has been largely positive about the pattern and pointed about the numbers.
Commenter psanford set out the broader shift:
Object store is quickly becoming the new core data substrate. Lets build kafka, but on s3. Lets build github, but on s3.
Commenter necubi, who identified himself in the thread as the post's author and K2's tech lead, agreed that every data system not requiring sub-100ms latency is moving to object storage, and noted that his team sits next to the R2 team and can co-evolve the products. The post is credited to Micah Wylde and Marc Selwan.
The sharpest exchange came from someone running the beta. Commenter e1g reported writes under a second but end-to-end delivery latency of p95 2.5 seconds and p99 7.5 seconds, and asked whether that was expected. A commenter answering for the team replied that the tail latency was higher than they would expect, that the Consume API has work to do on performance, and that read latency improvements should be visible within about a week.
A competitor offered the counterpoint. Commenter sensodine, who disclosed working on s2.dev in the same space, argued the opportunity extends below 100ms, pointing to faster object storage tiers such as S3 Express and GCS rapid buckets, both single-zone and therefore still needing quorum writes for regional durability. He described the underlying tension:
One of the tensions of course is how long to linger before flushing to object storage - you have to trade off directly between latency and cost of your API ops for PUTs.
His own service, he said, uses stateful backend processes constantly flushing multi-tenant objects containing records from many streams, reaching roughly 50ms p99 acknowledgment latency from the same region without ruining the unit economics.
Pricing drew the other substantive objection. Commenter nnx found the $0.04 per GB produced reasonable against other cloud event streams, but the identical charge to consume steep:
This means actual usage is $0.08/GB in the simplest case (one consumer) but fan-out consumer strategies get very expensive very fast.
That matters because fan-out is one of the use cases Cloudflare positions K2 for. Retention is charged separately at $0.02 per GB per month, and nothing is billed during the beta.
The same commenter defended the cost case against the obvious alternatives, saying K2's advantage over Google Pub/Sub is cost, particularly for longer retention, and that object storage makes it much cheaper than self-hosted or cloud-hosted Kafka such as Amazon MSK or Confluent, with no clusters to manage and consistent performance as data volume grows. He restated the trade in the same comment, putting produce and end-to-end latency at around 1s p99 against systems that rely on local disk replication.
Several commenters asked how K2 differs from AutoMQ and WarpStream, which apply the same object-storage pattern, and noted that Kafka itself now has diskless topic support. One answer came from another commenter rather than Cloudflare: it is built for the Cloudflare ecosystem, and using it standalone does not make much sense.
Kafka compatibility is on the roadmap, and the K2 tech lead was candid about why:
I'm not personally a huge fan of the kafka API, I think it's simultaneously too low level for normal users and too high level to deeply integrate into other systems (like stream processing engines), and requires a complex client library to use effectively.
K2 instead uses a lease-based consume API, where a consumer polls a subscription, receives a batch leased for five minutes, then acknowledges it, negatively acknowledges it for redelivery, or extends the lease. He said that design allows higher read parallelism, which matters when consumers are Workers that parallelize well but are individually not very powerful.
On the producing side, a Worker binding sends batches and surfaces whether a failure is worth retrying:
const result = await env.EVENTS.send([ { content: new TextEncoder().encode( JSON.stringify({ event: "page_view", path: new URL(request.url).pathname, timestamp: Date.now(), }), ), headers: { "content-type": "application/json" }, }, ]); if (!result.success) { console.error(`Produce failed: ${result.error.message}`); return new Response("Failed to record event", { status: result.error.retryable? 503: 500, }); } K2 represents data as bytes, leaving encoding to the application.
If these reactions are representative, the questions are about where the latency floor sits rather than whether the architecture makes sense. Cloudflare publishes a one-second produce figure, a user measured end-to-end tail latency several times that, and a competitor claims 50ms in a same-region configuration using stateful flushing rather than pure object storage.
Beta limits are 10GB of storage and 30 MB/s produce per stream, with a form for increases. Message keys and key-based ordering, multi-gigabyte-per-second write parallelism, push-based Worker consumers, a lower-latency express tier and Kafka client support are all listed as future work. Streams are created through the dashboard, the API, Wrangler, or cf, the command-line interface Cloudflare introduced the same week.
December 15–16, 2026. Examine how senior practitioners run agents, evals, model serving, and AI-assisted engineering in production, including what failed and what changed. Register Now.