K2, da Cloudflare, constrói streaming de eventos sobre o object storage R2

O que é o K2

A Cloudflare lançou recentemente o K2 em beta pública: um serviço serverless de streaming de eventos cujo armazenamento não é um log dedicado, e sim o próprio R2, o object storage da empresa, segundo reportagem do InfoQ. Por baixo, o K2 é um log duradouro e particionado que vive dentro do R2, com produção de eventos (produce) a cerca de 1 segundo de latência no p99, número publicado pela própria Cloudflare.

O projeto nasceu como encanamento interno, não como produto isolado. O Basin Pipelines, motor de processamento pull-based da Cloudflare, precisava de um lugar durável para estacionar eventos antes de lê-los e transformá-los. A saída óbvia seria Apache Kafka, mas Kafka pressupõe cluster fixo com disco local replicado, e o Pipelines roda numa borda de mais de 335 cidades, em fatias efêmeras de máquinas pequenas, conectadas pela internet pública, não por uma rede interna de data center.

R2 como log: a arquitetura por trás do K2

A saída da Cloudflare foi empilhar o serviço em cima de algo que já resolve durabilidade: o próprio R2, que oferece onze noves de durabilidade com APIs fortemente consistentes. Empurrar replicação e consenso para a camada de armazenamento deixa a camada de aplicação mais simples, e permite escalar computação e armazenamento de forma independente.

Object store não tem append, o que é um problema quando a abstração inteira é um log. O K2 contorna isso retendo escritas em memória num serviço de borda, esperando um instante para acumular mais eventos, e então gravando o lote como um arquivo de segmento no R2. As operações atômicas do R2 garantem ordenação e offsets incrementais, então não existe serviço de coordenação separado (nada de Zookeeper ou equivalente). Essa pequena espera para acumular o lote é exatamente a fonte da latência de produção.

Os números: o que a Cloudflare promete e o que o beta mostrou

A reação no Hacker News foi, em geral, favorável ao padrão arquitetural e pontual nas críticas aos números. O comentarista psanford resumiu a tese maior por trás do K2:

Object storage está rapidamente se tornando o novo substrato de dados central. Vamos construir um Kafka, só que sobre o S3. Vamos construir um GitHub, só que sobre o S3.

Object store is quickly becoming the new core data substrate. Lets build kafka, but on s3. Lets build github, but on s3.psanford, comentarista no Hacker News

O comentarista necubi, que se identificou na thread como autor do post original e tech lead↳Liderança técnica5 conteúdosLiderança técnica: a arte de inspirar desenvolvedores e gerar transformações 🚀Gestão Dev & TI · mai 2024Full Cycle lança pós-graduação que capacita devs para cargos de liderança técnicaDev (Back & Front) · mar 2024De Dev a Tech Leader: caminhos para se tornar um Tech Leader excepcionalGestão Dev & TI · ago 2024Ver tudo em Gestão Dev & TI → do K2, concordou com a leitura: todo sistema de dados que não exige latência sub-100ms está migrando para object storage, e disse que seu time trabalha ao lado do time do R2 e pode coevoluir os dois produtos. O post original é assinado por Micah Wylde e Marc Selwan.

A conversa mais afiada veio de quem já roda o beta. O comentarista e1g reportou escritas abaixo de um segundo, mas latência de entrega ponta a ponta de p95 em 2,5 segundos e p99 em 7,5 segundos, e perguntou se isso era esperado. Alguém respondendo pelo time confirmou que a latência de cauda está acima do esperado, que a API de consumo (Consume API) ainda tem trabalho de performance pela frente, e que melhorias de latência de leitura devem aparecer em cerca de uma semana.

Um concorrente trouxe o contraponto técnico. O comentarista sensodine, que se identificou como desenvolvedor do s2.dev, argumentou que a oportunidade real vai além dos 100ms, citando camadas de object storage mais rápidas como o S3 Express e os GCS rapid buckets (ambas de zona única, e por isso ainda dependentes de quorum de escrita para durabilidade regional). Ele descreveu a tensão central do desenho:

Uma das tensões, claro, é por quanto tempo segurar antes de gravar no object storage: você troca diretamente latência por custo de operações de API de PUT.

One of the tensions of course is how long to linger before flushing to object storage - you have to trade off directly between latency and cost of your API ops for PUTs.sensodine, desenvolvedor do s2.dev

Segundo ele, o próprio s2.dev usa processos de backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → com estado, fazendo flush constante de objetos multi-tenant com registros de vários streams, chegando a cerca de 50ms de latência de confirmação no p99 na mesma região, sem destruir a economia unitária do serviço.

Preço: produzir é barato, consumir dobra a conta

O preço também virou discussão. O comentarista nnx achou os $0,04 por GB produzido razoáveis frente a outros serviços de event streaming na nuvem, mas apontou que a cobrança idêntica para consumir encarece rápido o uso real:

Isso significa que o uso real é de $0,08 por GB no caso mais simples (um consumidor), mas estratégias de fan-out ficam caras muito rapidamente.

This means actual usage is $0.08/GB in the simplest case (one consumer) but fan-out consumer strategies get very expensive very fast.nnx, comentarista no Hacker News

Isso pesa porque fan-out, isto é, vários consumidores lendo o mesmo stream, é justamente um dos casos de uso que a Cloudflare usa para posicionar o K2. Retenção é cobrada à parte, a $0,02 por GB por mês, e nada é cobrado durante o beta. O mesmo comentarista defendeu o caso de custo frente às alternativas óbvias: o K2 seria mais barato que o Google Pub/Sub, especialmente com retenção longa, e bem mais barato que Kafka auto-hospedado ou gerenciado (como Amazon MSK ou Confluent), por não exigir cluster e manter performance consistente conforme o volume de dados cresce.

Onde o K2 entra no mapa: Kafka, AutoMQ, WarpStream, s2.dev

Várias perguntas na thread foram sobre como o K2 difere do AutoMQ e do WarpStream, que aplicam o mesmo padrão de object storage sobre Kafka, e observaram que o próprio Kafka já tem suporte experimental a tópicos diskless. Uma resposta, vinda de outro comentarista e não da Cloudflare, foi direta: o K2 é construído para o ecossistema Cloudflare, e usá-lo isolado, fora de Workers e Pipelines, não faz muito sentido hoje.

Compatibilidade com a API do Kafka está no roadmap, mas o tech lead do K2 foi direto sobre as reservas:

Eu pessoalmente não sou grande fã da API do Kafka. Acho que ela é ao mesmo tempo baixo nível demais para usuários normais e alto nível demais para integrar a fundo com outros sistemas (como motores de processamento de streams), e exige uma biblioteca cliente complexa para usar de forma eficaz.

I'm not personally a huge fan of the kafka API, I think it's simultaneously too low level for normal users and too high level to deeply integrate into other systems (like stream processing engines), and requires a complex client library to use effectively.necubi, tech lead do K2 na Cloudflare

Por isso o K2 usa uma API de consumo baseada em lease: o consumidor faz polling numa subscription, recebe um lote com lease de cinco minutos, e então confirma (ack), rejeita para reentrega (nack) ou estende o lease. Segundo ele, esse desenho permite maior paralelismo de leitura, importante quando os consumidores são Workers, que paralelizam bem mas individualmente têm pouca capacidade de processamento.

Produzindo eventos: o código

No lado da produção, um binding de Worker envia lotes e expõe se uma falha vale a pena tentar de novo:

const result = await env.EVENTS.send([
 {
 content: new TextEncoder().encode(
 JSON.stringify({
 event: "page_view",
 path: new URL(request.url).pathname,
 timestamp: Date.now(),
 }),
 ),
 headers: { "content-type": "application/json" },
 },
]);

if (!result.success) {
 console.error(`Produce failed: ${result.error.message}`);
 return new Response("Failed to record event", {
 status: result.error.retryable ? 503 : 500,
 });
}

O K2 representa dados como bytes puros, deixando a codificação (JSON, protobuf, o que for) a cargo da aplicação. Streams podem ser criados pelo dashboard, pela API, pelo Wrangler ou pelo cf, a interface de linha de comando que a Cloudflare lançou na mesma semana.

Limites do beta e o que falta

O beta tem limites claros: 10GB de armazenamento e 30 MB/s de produção por stream, com formulário para pedir aumento. Ordenação por chave de mensagem, paralelismo de escrita na casa de gigabytes por segundo, consumidores Workers via push (em vez de polling), uma camada express de latência menor e suporte a clientes Kafka estão todos listados como trabalho futuro, ainda sem data.

O que muda pra quem constrói no Brasil

Para quem já usa Cloudflare Workers, Pipelines ou R2 em produção no Brasil, o K2 abre um caso de uso que antes exigia operar um cluster Kafka à parte, ou pagar por um serviço gerenciado com cobrança por throughput fixo. A proposta é clara: trocar coordenação dedicada e disco replicado por object storage e uma espera de cerca de um segundo antes de cada lote virar segmento.

Mas os números da thread do Hacker News importam mais que o anúncio: a latência de cauda ponta a ponta medida por um usuário real (p99 de 7,5 segundos) é bem maior que o 1 segundo de produção divulgado pela Cloudflare, porque produzir não é o mesmo que entregar ao consumidor.

Quem está avaliando o K2 para um pipeline que não tolera minutos de atraso, mas também não precisa de sub-100ms, deveria testar a latência de consumo com sua própria carga antes de comprometer arquitetura a isso, e prestar atenção ao custo de fan-out: a cobrança igual para produzir e consumir significa que cada consumidor adicional de um mesmo stream dobra o custo, algo que pipelines com múltiplos times lendo o mesmo tópico sentem rápido no cartão.

Fonte: InfoQ