Un negozio online conferma un ordine. La fatturazione deve preparare una fattura, il team marketing vuole contare la vendita e il supporto desidera ritrovare ciò che è successo. Se il servizio marketing si ferma per qualche ora, bisogna perdere il suo evento, bloccare l’ordine o conservare una storia che potrà rileggere? Questo caso fittizio aiuta a comprendere l’importanza di Cloudflare K2 e a scegliere un primo tentativo.
Eseguire un compito o conservare una storia
Una coda di attività assomiglia a un elenco di lavori da svolgere: inviare una notifica, creare un documento, aggiornare un indice. Un lavoro completato generalmente non ha più bisogno di essere proposto allo stesso esecutore. Un registro degli eventi conserva invece dei fatti: un ordine è stato confermato, un indirizzo è cambiato, un documento è stato accettato. Diverse applicazioni potrebbero voler leggere questi fatti per motivi diversi.
Nel nostro negozio fittizio, la fatturazione e il marketing non seguono lo stesso ritmo. Il servizio di fatturazione non deve aspettare la fine di un calcolo statistico. Il supporto potrebbe voler ricostruire una cronologia più tardi. Il bisogno centrale è quindi una lettura indipendente della stessa storia, con una durata di conservazione scelta. Questa distinzione deriva dalla nostra analisi di architettura; non indica due categorie rigide in cui ogni prodotto entrerebbe automaticamente.
Ponete prima una domanda semplice: se cancellate un evento dopo il suo primo trattamento, quale uso diventa impossibile? Se nessun altro lettore ne ha bisogno e non è prevista alcuna rilettura, una coda già gestita può essere sufficiente. Se più applicazioni devono avanzare indipendentemente e riprendere una cronologia, un registro merita un esame più preciso.
Ciò che Cloudflare ha annunciato il 1° ottobre
Cloudflare ha aperto K2 in beta pubblica il 1° ottobre 2026. L'editore lo presenta come un diario duraturo di eventi, costruito sul suo storage R2, con sottoscrizioni per organizzare il consumo. Alcune funzionalità, inclusa la compatibilità diretta con Kafka, restano nella roadmap. Questo lancio non stabilisce alcuna equivalenza contrattuale con il vostro sistema attuale. Annuncio Cloudflare K2.
La documentazione consultata il 6 ottobre indica un accesso con Workers Paid, un limite iniziale di 10 GB per account e una conservazione di trenta giorni, con estensione su richiesta. Una conservazione è la durata durante la quale i dati rimangono conservati e possono ancora essere utilizzati per un ripristino. I limiti della beta devono essere riletti prima di un pilota. Documentazione K2.
Per la vostra decisione, distinguete l'accesso a un ambiente di test dalla sostituzione di un'infrastruttura. Il primo permette di verificare le ipotesi. Il secondo richiede di qualificare gli errori, gli impegni del fornitore, il volume reale e l'uscita del servizio. Una cronologia duratura non dimostra che ogni effetto di business sarà eseguito una sola volta, né che tutti gli eventi condividano un ordine globale.
Definire un evento che rimane comprensibile
Prima di scegliere la tecnologia, scrivete ciò che il vostro evento afferma. « Ordine confermato » è un fatto più preciso di « ordine modificato ». Il destinatario deve poter capire se il pagamento è autorizzato, incassato o solo atteso. Un nome ambiguo rischia di produrre una fattura nel momento sbagliato, anche con un trasporto perfettamente affidabile.
Ecco una struttura illustrativa, senza dati dei clienti e senza contratto specifico K2 :
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
L'identificativo dell'evento serve a riconoscere lo stesso fatto quando si ripresenta. La versione dello schema spiega come leggere la sua struttura. La data del fatto aziendale si distingue da quella della sua ricezione. Il contenuto deve rimanere minimo: un servizio di statistica non ha necessariamente bisogno di un indirizzo di consegna. Se un lettore ha bisogno di dettagli, decidete esplicitamente come li ottiene e quali diritti gli permettono di consultarli.
Definite anche cosa succederà quando lo schema evolverà. Un campo aggiunto può essere facoltativo per i vecchi lettori. Un cambiamento di significato generalmente richiede una nuova versione, con un periodo di coesistenza. Conservate esempi di ogni versione nel vostro ambiente di test: costituiscono un contratto leggibile tra i team, senza imporre un nuovo framework.
Rileggere senza ripetere gli effetti aziendali
Un consumatore è l'applicazione che legge gli eventi e ne trae un effetto. La difficoltà non si limita a ricevere un dato: cosa fare se il processo si interrompe dopo aver registrato una fattura ma prima di aver confermato il suo trattamento? Al riavvio, lo stesso evento può essere presentato di nuovo. La vostra progettazione deve prevedere questa possibilità.
L’idempotenza consiste qui nel rendere una ripetizione senza effetto aggiuntivo. Per un duplicato di fatturazione usato nel test, potete conservare l’identificativo del fatto già applicato. Questa regola deve essere valida quando due processi lavorano contemporaneamente; una semplice verifica seguita da una scrittura indipendente lascia una finestra di concorrenza.
Il seguente pseudocodice descrive un'intenzione, non un'API K2 né un'implementazione eseguita:
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
Quando l’effetto esce dalla vostra base, per esempio una chiamata a un fornitore di servizi di pagamento, questa transazione locale non è sufficiente. Bisogna esaminare una chiave di idempotenza riconosciuta dal destinatario o un meccanismo di coordinamento adeguato. Non inviate alcun pagamento reale in un esercizio di revisione. Una notifica di test o una scrittura in un archivio fittizio permette già di mettere alla prova la vostra regola.
Separate infine gli errori. Un guasto temporaneo può giustificare una ripresa limitata. Un evento incomprensibile richiede un'indagine. Un errore di business conosciuto deve essere registrato come tale. Una quarantena conserva gli elementi da esaminare senza bloccare indefinitamente l'intero flusso; definite il suo responsabile e la durata della conservazione.
Un pilota i cui risultati possono decidere
Il nostro protocollo proposto utilizza un produttore e due lettori, in uno spazio isolato. Il produttore emette solo ordini sintetici. Il primo lettore conta le vendite; il secondo crea schede di supporto fittizie. Una lista di riferimento contiene gli identificativi attesi. Nessun valore di throughput o di affidabilità è presentato qui come misurato.
Iniziate con il percorso normale. Verificate che ogni lettore ottenga i fatti necessari e che il suo risultato corrisponda al riferimento. Fermate poi un lettore mentre l’altro continua. Al ritorno, rilevate gli eventi ritrovati, le eventuali mancanze e le duplicazioni di presentazione. La durata dell’arresto deve rimanere compatibile con la conservazione scelta.
Presentate due volte lo stesso identificativo al componente simulato di archiviazione. Il criterio di accettazione è un solo effetto di business. Aggiungete un evento di versione sconosciuta e un guasto simulato dello storage: dovrete poter spiegare il trattamento ottenuto e recuperare l’elemento da investigare. Misurate il ritardo tra emissione e risultato, le scritture di ripresa e i volumi conservati, con condizioni di prova documentate.
| Questione di qualificazione | Prova da raccogliere nel pilota |
|---|---|
| I lettori procedono indipendentemente? | Progressione di ciascuno durante la pausa dell’altro |
| Una ripresa ritrova i fatti autorizzati? | Confronto degli identificativi con il riferimento |
| Una ripetizione crea un doppio effetto? | Numero di effetti nella memorizzazione fittizia |
| Un errore rimane spiegabile? | Stato, motivo e possibilità di ripresa controllata |
Questa griglia è un metodo Partitech. Descrive delle osservazioni da produrre, senza costituire un risultato del fornitore.
Preparare un'uscita prima di una migrazione
Conservate il vostro schema di evento al di fuori delle particolarità del servizio. Identificate come esportare i dati ancora utili, ricostruire il progresso di un lettore e ripristinare un ambiente di test. Verificate la fedeltà di un'esportazione rileggendo alcuni esempi di ogni versione, invece di accontentarvi di un file scaricato.
In caso di una eventuale migrazione, un rollback non può semplicemente riattivare due consumatori che fanno entrambi fatturazione. È necessaria una regola che indichi l'unico meccanismo autorizzato a produrre l'effetto, quindi un punto di ripresa verificabile. Il pilota deve rimanere senza effetto reale finché questa coordinazione non è stabilita.
Scegliete una coda semplice se il vostro bisogno è un lavoro da svolgere senza storia condivisa. Valutate un registro se più lettori devono riprendere la stessa storia secondo ritmi diversi. K2 rende questa prova accessibile nel suo perimetro beta; la decisione finale dipende dalle prove di ripresa, dall'idempotenza e dalle condizioni di uscita ottenute nel vostro ambiente.
Fonti e data di verifica
Fonti primarie aperte il 6 ottobre 2026: annuncio K2 del 1° ottobre e documentazione K2. Gli scenari, la griglia e il pseudocodice sono proposte originali, non eseguite in questo articolo.