Una tienda en línea confirma un pedido. La facturación debe preparar una factura, el equipo de marketing quiere contar la venta y el soporte desea saber lo que ha ocurrido. Si el servicio de marketing se detiene unas horas, ¿hay que perder su evento, bloquear el pedido o conservar una historia que podrá releer? Este caso ficticio ayuda a entender el interés de Cloudflare K2 y a elegir un primer intento.
Ejecutar una tarea o conservar una historia
Una cola de tareas se parece a una lista de trabajos por realizar: enviar una notificación, elaborar un documento, actualizar un índice. Un trabajo terminado generalmente ya no necesita ser ofrecido al mismo ejecutor. Un registro de eventos conserva más bien hechos: un pedido ha sido confirmado, una dirección ha cambiado, un documento ha sido aceptado. Varias aplicaciones pueden querer leer estos hechos por diferentes razones.
En nuestra tienda ficticia, la facturación y el marketing no siguen el mismo ritmo. El servicio de facturación no debe esperar al final de un cálculo estadístico. El soporte puede querer reconstruir una cronología más tarde. La necesidad central es, por lo tanto, una lectura independiente de la misma historia, con un tiempo de conservación elegido. Esta distinción proviene de nuestro análisis de arquitectura; no designa dos categorías rígidas en las que todo producto entraría automáticamente.
Primero haga una pregunta simple: si borra un evento después de su primer procesamiento, ¿qué uso se vuelve imposible? Si ningún otro lector lo necesita y no se prevé ninguna relectura, puede ser suficiente una cola ya controlada. Si varias aplicaciones deben avanzar de manera independiente y retomar un historial, un registro merece un examen más detallado.
Lo que Cloudflare anunció el 1 de octubre
Cloudflare abrió K2 en beta pública el 1 de octubre de 2026. El editor lo presenta como un registro duradero de eventos, construido sobre su almacenamiento R2, con suscripciones para organizar el consumo. Algunas capacidades, incluida la compatibilidad directa con Kafka, permanecen en la hoja de ruta. Este lanzamiento no establece ninguna equivalencia de contrato con su sistema actual. Anuncio Cloudflare K2.
La documentación consultada el 6 de octubre indica un acceso con Workers Paid, un límite inicial de 10 GB por cuenta y una retención de treinta días, con extensión a solicitud. Una retención es el período durante el cual los datos se mantienen y todavía pueden usarse para una recuperación. Los límites de la versión beta deben ser revisados antes de un piloto. Documentación K2.
Para su decisión, distinga el acceso a un entorno de prueba del reemplazo de una infraestructura. El primero permite verificar hipótesis. El segundo exige calificar los errores, los compromisos del proveedor, el volumen real y la salida del servicio. Un historial duradero no prueba que cada efecto de negocio se ejecutará una sola vez, ni que todos los eventos compartan un orden global.
Definir un evento que siga siendo comprensible
Antes de elegir la tecnología, escriba lo que su evento afirma. «Pedido confirmado» es un hecho más preciso que «pedido modificado». El destinatario debe poder comprender si el pago está autorizado, cobrado o solo esperado. Un nombre ambiguo corre el riesgo de producir una factura en el momento equivocado, incluso con un transporte perfectamente fiable.
Aquí hay una estructura ilustrativa, sin datos de clientes y sin contrato propio de 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
El identificador del evento sirve para reconocer el mismo hecho cuando vuelve a ocurrir. La versión del esquema explica cómo leer su estructura. La fecha del hecho de negocio se distingue de la de su recepción. El contenido debe permanecer mínimo: un servicio de estadísticas no necesariamente necesita una dirección de entrega. Si un lector necesita detalles, decida explícitamente cómo los obtiene y qué derechos le autorizan a consultarlos.
Defina también lo que sucederá cuando el esquema evolucione. Un campo agregado puede ser opcional para los lectores antiguos. Un cambio de significado generalmente requiere una nueva versión, con un período de coexistencia. Mantenga ejemplos de cada versión en su entorno de prueba: constituyen un contrato legible entre equipos, sin imponer un nuevo marco.
Reproducir sin repetir los efectos del negocio
Un consumidor es la aplicación que lee los eventos y genera un efecto a partir de ellos. La dificultad no se limita a recibir un dato: ¿qué hacer si el proceso se detiene después de haber registrado una factura pero antes de haber confirmado su procesamiento? Al reanudarse, el mismo evento puede presentarse de nuevo. Su diseño debe prever esta posibilidad.
La idempotencia consiste aquí en hacer que una repetición no tenga efecto adicional. Para un doble de prueba de facturación, puede conservarse el identificador del hecho ya aplicado. Esta regla debe mantenerse cuando dos procesos trabajan al mismo tiempo; una simple verificación seguida de una escritura independiente deja una ventana de condición de carrera.
El pseudocódigo siguiente describe una intención, no una API K2 ni una implementación ejecutada:
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
Cuando el efecto sale de su base de datos, por ejemplo una llamada a un proveedor de pagos, esta transacción local no es suficiente. Es necesario examinar una clave de idempotencia reconocida por el destinatario o un mecanismo de coordinación adecuado. No envíe ningún pago real en un ejercicio de revisión. Una notificación de prueba o una escritura en un almacenamiento ficticio ya permite probar su regla.
Separe finalmente los errores. Una avería temporal puede justificar un número limitado de reintentos. Un evento incomprensible llama a una investigación. Un error de negocio conocido debe registrarse como tal. Una cuarentena conserva los elementos a examinar sin bloquear indefinidamente todo el flujo; fije su responsable y su duración de conservación.
Un piloto cuyos resultados pueden decidir
Nuestro protocolo propuesto utiliza un productor y dos lectores, en un espacio aislado. El productor emite únicamente pedidos sintéticos. El primer lector cuenta las ventas; el segundo crea fichas de soporte ficticias. Una lista de referencia contiene los identificadores esperados. Ningún valor de rendimiento o fiabilidad se presenta aquí como medido.
Comience por el recorrido normal. Verifique que cada lector obtenga los hechos necesarios y que su resultado coincida con la referencia. Luego, detenga a un lector mientras el otro continúa. Al reanudar, anote los eventos recuperados, las posibles ausencias y las duplicaciones de presentación. La duración de la parada debe permanecer compatible con la conservación elegida.
Presente dos veces el mismo identificador al doble de almacenamiento. El criterio de aceptación es un solo efecto de negocio. Agregue un evento de versión desconocida y una falla simulada del almacenamiento: debe poder explicar el procesamiento obtenido y localizar el elemento a investigar. Mida el retraso entre emisión y resultado, las escrituras de recuperación y los volúmenes conservados, con condiciones de prueba documentadas.
| Pregunta de calificación | Prueba a recopilar en el piloto |
|---|---|
| ¿Los lectores avanzan de forma independiente? | Progresión de cada uno durante la parada del otro |
| ¿Una reanudación recupera los hechos autorizados? | Comparación de los identificadores con la referencia |
| ¿Una repetición crea un doble efecto? | Número de efectos en el almacenamiento simulado |
| ¿Sigue siendo explicable un error? | Estado, motivo y posibilidad de reanudación controlada |
Esta cuadrícula es un método de Partitech. Describe observaciones a realizar, sin constituir un resultado del proveedor.
Preparar una salida antes de una migración
Conserve su esquema de eventos fuera de las particularidades del servicio. Identifique cómo exportar los datos aún útiles, reconstruir el progreso de un lector y restaurar un entorno de prueba. Verifique la fidelidad de una exportación leyendo algunos ejemplos de cada versión, en lugar de limitarse a un archivo descargado.
En caso de una posible migración, una reversión no puede simplemente reactivar a dos consumidores que emiten facturas a la vez. Se necesita una regla que designe el único mecanismo autorizado a producir el efecto, luego un punto de reanudación verificable. El piloto debe permanecer sin efecto real mientras no se establezca esta coordinación.
Elija una cola simple si su necesidad es un trabajo a realizar sin historia compartida. Evalúe un registro si varios lectores deben retomar la misma historia según diferentes ritmos. K2 hace este ensayo accesible dentro de su perímetro beta; la decisión final depende de las pruebas de recuperación, de la idempotencia y de las condiciones de salida obtenidas en su entorno.
Fuentes y fecha de verificación
Fuentes primarias abiertas el 6 de octubre de 2026: anuncio K2 del 1 de octubre y documentación K2. Los escenarios, la cuadrícula y el pseudocódigo son propuestas originales, no ejecutadas en este artículo.