Cloudflare K2: el Kafka serverless que quiere enterrar los brokers

Kafka funciona, pero duele operarlo

Kafka resolvió un problema gigantesco: desacoplar productores y consumidores para que los eventos no se pierdan cuando alguien va lento o se cae. Pero esa solución vino con un precio brutal: clusters que hay que dimensionar, replicar, re-balancear, parchear y mantener 24/7.

La ecuación es simple: cuantas más garantías duras quieres, más complejidad operacional cargas sobre tu equipo. Para muchas startups, esa complejidad termina siendo el verdadero costo, no el hardware.

Cloudflare decidió rehacerlo sobre R2

El truco está en no reinventar el consenso. En vez de correr brokers distribuidos con su propio protocolo de replicación, Cloudflare K2 construye un log particionado directamente sobre R2, el object storage con 11 nueves de durabilidad.

Al descargar la replicación y la consistencia fuerte a la capa de almacenamiento, la aplicación se vuelve radicalmente más simple. Eso permite escalar almacenamiento y cómputo por separado, guardar terabytes a precio bajo y evitar el mantenimiento de clusters Kafka tradicionales.

La contrapartida es latencia. Escribir en object storage no es tan rápido como disco local. En la beta pública de K2, la latencia de producción ronda un segundo en el percentil 99. Para pipelines de analytics, ETL, ingesta masiva, auditoría o buffering a largo plazo, eso es perfectamente aceptable. Para trading de microsegundos, no lo es.

K2 vs Queues vs Pipelines: cuándo usar cada uno

La distinción es clara. Cloudflare ya tenía Queues, para trabajos individuales con reintentos y colas de mensajes muertos, y Basin Pipelines, para ingerir eventos directo hacia R2 o tablas Iceberg. K2 apunta a un hueco distinto: movimiento de datos a gran escala, retención a largo plazo y consumo en fan-out, donde varios consumidores independientes leen al mismo ritmo.

Mientras Queues opera a nivel de mensaje con lógica granular, K2 opera por lotes para procesar eficientemente volúmenes enormes. Ese batching es exactamente lo que produce la mayor latencia de productor frente a una cola. Y si lo que quieres es volcar datos a Iceberg o buckets R2, Pipelines te ahorra trabajo; si quieres procesar con lógica propia o escribir a otro destino, K2 es tu opción.

Desacoplar sin convertirlo en una pesadilla

El mayor dolor de Kafka nunca fue el código, fue la operación. Cuando un consumidor se cae por horas o días, un log durable bien diseñado sigue guardando todo. Y cuando necesitas que un segundo consumidor lea el mismo stream sin romper al primero, el modelo de fan-out cobra sentido de verdad.

Cloudflare lleva esta idea a su filosofía serverless: pagas por lo que usas, no mantienes máquinas durmiendo para cubrir picos. Crear un stream, producir por HTTP o por Worker Binding, y crear suscripciones para dividir la lectura entre varios consumidores es lo bastante simple como para que un equipo pequeño lo ponga en producción el mismo día.

Para un dev en Latinoamérica esto significa algo concreto: el costo de operar infraestructura deja de ser la barrera de entrada. Ya no necesitas un DevOps dedicado para mantener el bus de eventos de tu e-commerce, tu app de pagos o tu telemetría. Eso abre la puerta a equipos de dos o tres personas que antes simplemente no podían permitirse esta arquitectura.

El mensaje incómodo

Cloudflare K2 no viene a reemplazar Kafka en todos los casos. Si necesitas latencias sub-10ms, sigue requiriendo un cluster dedicado y afinado a mano. Pero para ingesta masiva, buffering resistente y procesamiento por lotes, el streaming serverless construido sobre object storage deja de ser experimento y empieza a tener todo el sentido.

La tendencia más importante aquí no es K2 en sí. Es que los tres grandes (Cloudflare, AWS y Google) están reposicionando el almacenamiento de objetos como la capa base de la arquitectura serverless. El log durable ya no es un producto aparte: es object storage con unas pocas primitivas encima.

Comparte esto si crees que el verdadero costo de un sistema distribuido no son los servidores, sino las horas que tu equipo pierde operándolos.