Une boutique en ligne confirme une commande. La facturation doit préparer une facture, l’équipe marketing veut compter la vente et le support souhaite retrouver ce qui s’est passé. Si le service marketing s’arrête quelques heures, faut-il perdre son événement, bloquer la commande ou conserver une histoire qu’il pourra relire ? Ce cas fictif aide à comprendre l’intérêt de Cloudflare K2 et à choisir un premier essai.
Exécuter une tâche ou conserver une histoire
Une file de tâches ressemble à une liste de travaux à accomplir : envoyer une notification, fabriquer un document, mettre à jour un index. Un travail terminé n’a généralement plus besoin d’être proposé au même exécutant. Un journal d’événements conserve plutôt des faits : une commande a été confirmée, une adresse a changé, un document a été accepté. Plusieurs applications peuvent vouloir lire ces faits pour des raisons différentes.
Dans notre boutique fictive, la facturation et le marketing ne suivent pas le même rythme. Le service de facturation ne doit pas attendre la fin d’un calcul statistique. Le support peut vouloir reconstruire une chronologie plus tard. Le besoin central est donc une lecture indépendante de la même histoire, avec une durée de conservation choisie. Cette distinction vient de notre analyse d’architecture ; elle ne désigne pas deux catégories rigides dans lesquelles tout produit entrerait automatiquement.
Posez d’abord une question simple : si vous effacez un événement après son premier traitement, quel usage devient impossible ? Si aucun autre lecteur n’en a besoin et qu’aucune relecture n’est prévue, une file déjà maîtrisée peut suffire. Si plusieurs applications doivent avancer indépendamment et reprendre un historique, un journal mérite un examen plus précis.
Ce que Cloudflare a annoncé le 1er octobre
Cloudflare a ouvert K2 en bêta publique le 1er octobre 2026. L’éditeur le présente comme un journal durable d’événements, construit sur son stockage R2, avec des abonnements pour organiser la consommation. Certaines capacités, dont la compatibilité directe avec Kafka, restent dans la feuille de route. Ce lancement n’établit aucune équivalence de contrat avec votre système actuel. Annonce Cloudflare K2.
La documentation consultée le 6 octobre indique un accès avec Workers Paid, un plafond initial de 10 Go par compte et une rétention de trente jours, avec extension sur demande. Une rétention est la durée pendant laquelle les données restent conservées et peuvent encore servir à une reprise. Les limites de bêta doivent être relues avant un pilote. Documentation K2.
Pour votre décision, distinguez l’accès à un environnement d’essai du remplacement d’une infrastructure. Le premier permet de vérifier des hypothèses. Le second exige de qualifier les erreurs, les engagements du fournisseur, le volume réel et la sortie du service. Un historique durable ne prouve pas que chaque effet métier sera exécuté une seule fois, ni que tous les événements partagent un ordre global.
Définir un événement qui reste compréhensible
Avant de choisir la technologie, écrivez ce que votre événement affirme. « Commande confirmée » est un fait plus précis que « commande modifiée ». Le destinataire doit pouvoir comprendre si le paiement est autorisé, encaissé ou seulement attendu. Un nom ambigu risque de produire une facture au mauvais moment, même avec un transport parfaitement fiable.
Voici une structure illustrative, sans donnée client et sans contrat propre à 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’identifiant de l’événement sert à reconnaître le même fait quand il revient. La version de schéma explique comment lire sa structure. La date du fait métier se distingue de celle de sa réception. Le contenu doit rester minimal : un service de statistiques n’a pas nécessairement besoin d’une adresse de livraison. Si un lecteur a besoin de détails, décidez explicitement comment il les obtient et quels droits l’autorisent à les consulter.
Définissez aussi ce qui arrivera lorsque le schéma évoluera. Un champ ajouté peut être facultatif pour les anciens lecteurs. Un changement de sens appelle généralement une nouvelle version, avec une période de coexistence. Gardez des exemples de chaque version dans votre environnement de test : ils constituent un contrat lisible entre équipes, sans imposer un nouveau framework.
Rejouer sans répéter les effets métier
Un consommateur est l’application qui lit les événements et en tire un effet. La difficulté ne se limite pas à recevoir une donnée : que faire si le processus s’arrête après avoir enregistré une facture mais avant d’avoir confirmé son traitement ? À la reprise, le même événement peut être présenté à nouveau. Votre conception doit prévoir cette possibilité.
L’idempotence consiste ici à rendre une répétition sans effet supplémentaire. Pour un double de facturation utilisé en test, vous pouvez conserver l’identifiant du fait déjà appliqué. Cette règle doit tenir quand deux processus travaillent en même temps ; une simple vérification suivie d’une écriture indépendante laisse une fenêtre de course.
Le pseudocode suivant décrit une intention, pas une API K2 ni une implémentation exécutée :
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
Quand l’effet sort de votre base, par exemple un appel à un prestataire de paiement, cette transaction locale ne suffit pas. Il faut examiner une clé d’idempotence reconnue par le destinataire ou un mécanisme de coordination adapté. N’envoyez aucun paiement réel dans un exercice de relecture. Une notification de test ou une écriture dans un stockage factice permet déjà d’éprouver votre règle.
Séparez enfin les erreurs. Une panne temporaire peut justifier une reprise bornée. Un événement incompréhensible appelle une investigation. Une erreur métier connue doit être enregistrée comme telle. Une quarantaine conserve les éléments à examiner sans bloquer indéfiniment tout le flux ; fixez son responsable et sa durée de conservation.
Un pilote dont les résultats peuvent décider
Notre protocole proposé utilise un producteur et deux lecteurs, sur un espace isolé. Le producteur émet uniquement des commandes synthétiques. Le premier lecteur compte les ventes ; le second crée des fiches de support factices. Une liste de référence contient les identifiants attendus. Aucune valeur de débit ou de fiabilité n’est présentée ici comme mesurée.
Commencez par le trajet normal. Vérifiez que chaque lecteur obtient les faits nécessaires et que son résultat correspond à la référence. Arrêtez ensuite un lecteur pendant que l’autre continue. À la reprise, relevez les événements retrouvés, les éventuels manques et les duplications de présentation. La durée de l’arrêt doit rester compatible avec la conservation choisie.
Présentez deux fois le même identifiant au double de stockage. Le critère d’acceptation est un seul effet métier. Ajoutez un événement de version inconnue et une panne simulée du stockage : vous devez pouvoir expliquer le traitement obtenu et retrouver l’élément à investiguer. Mesurez le retard entre émission et résultat, les écritures de reprise et les volumes conservés, avec des conditions d’essai documentées.
| Question de qualification | Preuve à recueillir dans le pilote |
|---|---|
| Les lecteurs avancent-ils indépendamment ? | Progression de chacun pendant l’arrêt de l’autre |
| Une reprise retrouve-t-elle les faits autorisés ? | Comparaison des identifiants avec la référence |
| Une répétition crée-t-elle un double effet ? | Nombre d’effets dans le stockage factice |
| Une erreur reste-t-elle explicable ? | État, motif et possibilité de reprise contrôlée |
Cette grille est une méthode Partitech. Elle décrit des observations à produire, sans constituer un résultat du fournisseur.
Préparer une sortie avant une migration
Conservez votre schéma d’événement en dehors des particularités du service. Identifiez comment exporter les données encore utiles, reconstruire la progression d’un lecteur et restaurer un environnement de test. Vérifiez la fidélité d’un export en relisant quelques exemples de chaque version, plutôt qu’en vous contentant d’un fichier téléchargé.
Lors d’une migration éventuelle, un retour arrière ne peut pas simplement réactiver deux consommateurs qui facturent tous deux. Il faut une règle qui désigne le seul mécanisme autorisé à produire l’effet, puis un point de reprise vérifiable. Le pilote doit rester sans effet réel tant que cette coordination n’est pas établie.
Choisissez une file simple si votre besoin est un travail à accomplir sans histoire partagée. Qualifiez un journal si plusieurs lecteurs doivent reprendre la même histoire selon des rythmes différents. K2 rend cet essai accessible dans son périmètre de bêta ; la décision finale dépend des preuves de reprise, de l’idempotence et des conditions de sortie obtenues dans votre environnement.
Sources et date de vérification
Sources primaires ouvertes le 6 octobre 2026 : annonce K2 du 1er octobre et documentation K2. Les scénarios, la grille et le pseudocode sont des propositions originales, non exécutées dans cet article.