An online store confirms an order. Billing must prepare an invoice, the marketing team wants to count the sale, and support wants to find out what happened. If the marketing service stops for a few hours, should its event be lost, should the order be blocked, or should a history be kept that they can read later? This fictional case helps to understand the interest of Cloudflare K2 and to choose a first attempt.
Execute a task or preserve a story
A task queue is like a list of jobs to be done: sending a notification, creating a document, updating an index. A completed job generally no longer needs to be offered to the same executor. An event log rather keeps track of facts: an order has been confirmed, an address has changed, a document has been accepted. Several applications may want to read these facts for different reasons.
In our fictitious store, billing and marketing do not follow the same pace. The billing service should not have to wait for the end of a statistical calculation. Support may want to rebuild a timeline later. The central need is therefore an independent reading of the same story, with a chosen retention period. This distinction comes from our architectural analysis; it does not designate two rigid categories into which every product would automatically fit.
First, ask a simple question: if you delete an event after its first processing, what use becomes impossible? If no other reader needs it and no re-reading is planned, an already controlled queue may suffice. If several applications need to progress independently and resume a history, a log deserves a more precise examination.
What Cloudflare announced on October 1
Cloudflare opened K2 in public beta on October 1, 2026. The publisher presents it as a durable event log, built on its R2 storage, with subscriptions to organize consumption. Some capabilities, including direct compatibility with Kafka, remain on the roadmap. This launch does not establish any contractual equivalence with your current system. Announcement Cloudflare K2.
The documentation consulted on October 6 indicates an access with Workers Paid, an initial cap of 10 GB per account and a retention of thirty days, with extension on request. A retention is the period during which data remains stored and can still be used for a recovery. Beta limits should be reviewed before a pilot. Documentation K2.
For your decision, distinguish access to a test environment from the replacement of an infrastructure. The first allows you to verify hypotheses. The second requires qualifying errors, supplier commitments, actual volume, and the ability to exit the service. A lasting history does not prove that each business effect will be executed only once, nor that all events share a global order.
Define an event that remains understandable
Before choosing the technology, write down what your event states. "Order confirmed" is a more precise fact than "order modified." The recipient must be able to understand whether the payment is authorized, collected, or merely expected. An ambiguous name risks producing an invoice at the wrong time, even with perfectly reliable transport.
Here is an illustrative structure, without client data and without a K2-specific contract:
event_id : demo-commande-001
schema_version : 1
occurred_at : date UTC du fait métier
event_type : commande_confirmee
payload : identifiant fictif de commande et devise
The event identifier is used to recognize the same fact when it occurs again. The schema version explains how to read its structure. The date of the business fact is distinct from that of its reception. The content should remain minimal: a statistics service does not necessarily need a delivery address. If a reader needs details, explicitly decide how they obtain them and what rights authorize them to access them.
Also define what will happen when the schema evolves. An added field can be optional for older readers. A change in meaning generally calls for a new version, with a period of coexistence. Keep examples of each version in your test environment: they constitute a readable contract between teams, without imposing a new framework.
Replay without repeating the business effects
A consumer is the application that reads events and derives an effect from them. The difficulty is not limited to receiving data: what should be done if the process stops after recording an invoice but before confirming its processing? Upon resumption, the same event may be presented again. Your design must account for this possibility.
Idempotence here consists of making a repetition without additional effect. For a billing test double, you can keep the identifier of the action already applied. This rule must hold when two processes are working at the same time; a simple check followed by an independent write leaves a race window.
The following pseudocode describes an intention, not a K2 API or an implementation executed here:
commencer une transaction locale
réserver event_id sous une contrainte d'unicité
si cet identifiant est déjà traité : terminer sans nouvel effet
vérifier la version et les règles métier
enregistrer la facture fictive et le résultat du traitement
valider la transaction
confirmer le traitement selon le contrat du transport
When the effect leaves your database, for example a call to a payment provider, this local transaction is not enough. You need to examine an idempotency key recognized by the recipient or a suitable coordination mechanism. Do not send any real payment in a review exercise. A test notification or an entry in a dummy storage is already enough to test your rule.
Finally, separate the errors. A temporary failure may justify a limited retry. An incomprehensible event calls for an investigation. A known business error must be recorded as such. A quarantine keeps the items to be examined without indefinitely blocking the entire flow; assign its responsible person and its retention period.
A pilot whose results can decide
Our proposed protocol uses one producer and two readers, on an isolated space. The producer only issues synthetic orders. The first reader counts the sales; the second creates dummy support tickets. A reference list contains the expected identifiers. No throughput or reliability value is presented here as measured.
Start with the normal process. Check that each reader obtains the necessary facts and that their result matches the reference. Then stop one reader while the other continues. Upon resumption, record the recovered events, any missing items, and any duplicate presentations. The duration of the stop must remain compatible with the chosen retention.
Present the same identifier twice to the storage double. The acceptance criterion is a single business effect. Add an event of unknown version and a simulated storage failure: you must be able to explain the processing obtained and find the element to investigate. Measure the delay between emission and result, the recovery writes, and the stored volumes, with documented test conditions.
| Qualification question | Evidence to be collected in the pilot |
|---|---|
| Do the readers move independently? | Progression of each during the other's stoppage |
| Does a resumption recover the authorized facts? | Comparison of identifiers with the reference |
| Does a repetition create a double effect? | Number of effects in dummy storage |
| Is a mistake still explainable? | State, reason and possibility of controlled resumption |
This grid is a Partitech method. It describes observations to be made, without constituting a result from the supplier.
Prepare an exit plan before a migration
Keep your event schema separate from the specifics of the service. Identify how to export the data that is still useful, rebuild a reader's progress, and restore a test environment. Check the accuracy of an export by reviewing a few examples of each version, rather than just relying on a downloaded file.
In the event of a possible migration, a rollback cannot simply reactivate two consumers that both issue invoices. A rule is needed to designate the only mechanism authorized to produce the effect, and then a verifiable resumption point. The pilot must remain without real effect as long as this coordination is not established.
Choose a simple queue if your need is a task to be completed without a shared story. Evaluate an event log if multiple readers need to pick up the same story at different paces. K2 makes this trial accessible within its beta scope; the final decision depends on evidence of recovery, idempotence, and exit conditions obtained in your environment.
Sources and verification date
Primary sources opened on October 6, 2026: announcement K2 from October 1 and documentation K2. The scenarios, the grid, and the pseudocode are original proposals, not executed in this article.