Como usar Cloudflare K2 em workers hoje

O Cloudflare K2 é um log de eventos append-only construído sobre o R2, o armazenamento de objetos da Cloudflare. Ele promete entrega at-least-once, retenção de 7 dias por padrão e produção com cerca de 1 segundo de latência no p99 durante o beta.

O que é o Cloudflare K2 e quando ele aparece no mapa

O Cloudflare K2 é um log de eventos distribuído em beta público desde 1º de outubro de 2026, construído sobre o R2, o armazenamento de objetos da Cloudflare. Ele existe para resolver um problema concreto: com chamadas HTTP diretas entre serviços, se o consumidor está fora do ar, o evento se perde. No exemplo do anúncio, um pedido de e-commerce precisa chegar a analytics, detecção de fraude e e-mail; se o serviço de e-mail cai, ele nunca vê aquele pedido.

A forma é familiar para quem conhece o Kafka: um log append-only de registros, com vários leitores independentes sobre o mesmo fluxo. A diferença está embaixo, na camada de armazenamento e coordenação, e é ela que explica tanto os ganhos quanto os custos que você vai ler abaixo.

Um aviso antes de qualquer decisão: no roadmap atual, suporte a clientes Kafka está planejado sem data definida. Hoje você acessa o K2 por binding de Workers ou pela API HTTP.

Como o log sobre object storage funciona sem brokers

No Kafka, cada broker replica dados para os outros e essa cópia mantém tudo seguro. O K2 terceiriza esse trabalho para o R2. As escritas se acumulam brevemente em memória, são seladas em um arquivo de segmento e gravadas no fim do log. Cada registro recebe um offset que só cresce, e a Cloudflare afirma que não precisa de ZooKeeper nem KRaft: as operações atômicas do R2 garantem a ordenação.

Essa escolha tem uma consequência direta. Segundo o anúncio, o K2 precisa gravar arquivos grandes o suficiente para compensar o custo de cada operação no object storage. É como um depósito que espera juntar caixas antes de despachar. A espera curta pelo lote é uma das duas causas dos cerca de 1 segundo de latência que veremos mais adiante.

Sobre durabilidade, a documentação do R2 descreve 11 noves de durabilidade anual projetada, e só confirma a escrita depois que os dados persistem em disco. O serviço à frente do armazenamento funciona mais como mesa de embalagem do que como cofre: a prateleira é que guarda.

Assinaturas independentes e retenção: como o serviço offline recupera o pedido

Cada consumidor recebe sua própria assinatura, e cada assinatura mantém um bookmark com a posição dela no log. Analytics, fraude e e-mail leem os mesmos segmentos, e nenhum leitor move o marcador do outro. Enquanto o e-mail está fora do ar, os segmentos continuam sendo gravados, e o bookmark dele simplesmente espera.

Quando o e-mail volta, o marcador está onde ficou. Ele lê o pedido e nada foi descartado. Mas há um relógio: a retenção padrão é de 7 dias, com máximo de 30 e mínimo de 1 hora. Se a queda do serviço durar mais que o período configurado, os registros mais antigos saem da prateleira antes de o bookmark chegar até eles.

Os limites documentados no beta definem o tamanho do desenho possível. Vale conferir se cabem no seu caso antes de planejar a migração:

• Até 100 assinaturas por stream.
• Cada registro suporta cerca de 1 megabyte.
• Uma assinatura nova pode começar do registro mais antigo ainda retido e ler dali para frente.
• Retenção entre 1 hora e 30 dias, com 7 dias como padrão.

Latência do Cloudflare K2 versus Kafka: o que os números mostram

O número oficial da Cloudflare é de cerca de 1 segundo de latência de produção no percentil 99, ou seja, 99 gravações em 100 terminam mais rápido que isso. As causas nomeadas são duas: a velocidade do object storage e a espera pelo lote. Cada registro fica na mesa até o período curto acabar, o segmento inteiro vai ao R2, e só então o produtor recebe a confirmação.

Para contextualizar, o Warpstream, log compatível com Kafka também sobre object storage, documenta 500 milissegundos no p99 para produção e 900 milissegundos ponta a ponta nos padrões padrão. É um sistema diferente, e a comparação não é um teste frente a frente com o K2.

Medidas da comunidade contam outra parte da história. No Hacker News, um usuário relatou escritas abaixo de 1 segundo, mas entrega ponta a ponta de 2,5 segundos no p95 e 7,5 segundos no p99 em clusters iniciais do beta. É um teste individual, não um benchmark oficial. Na mesma discussão, alguém identificado como ligado à equipe do K2 escreveu que a latência de produção e ponta a ponta roda mais alta que sistemas em disco local como o Kafka, em torno de 1 segundo no p99. A resposta do roadmap é um tier express de menor latência, ainda planejado.

A conclusão honesta: o dado publicado pela Cloudflare cobre só a produção. Se o seu consumidor precisa de entrega rápida, espere mais que 1 segundo até a ponta.

Armadilhas de produtor e consumidor que a documentação revela

O K2 promete entrega at-least-once, e isso significa duplicatas. Um registro pode aparecer mais de uma vez, então seu serviço de e-mail pode enviar o mesmo recibo duas vezes. Construa consumidores que toleram repetição: chaveie cada e-mail pelo ID do pedido e pule os já enviados.

O lote também muda a semântica de retentativa. Cada lote alugado tem um lease de 5 minutos, e os mesmos registros nunca vão para dois workers ao mesmo tempo. Se o worker responde nack, o lote inteiro é reentregue. Não existe nova tentativa de mensagem única: um pedido que falhou traz o loto todo de volta.

Do lado da produção, a escrita em lote é tudo ou nada, mas a chamada de envio não lança erro. Quando o K2 rejeita um lote, ele retorna um objeto de resultado, e você mesmo verifica result.success. Ignorar essa checagem faz um lote rejeitado parecer idêntico a um aceito, até alguém perguntar pelos pedidos de terça.

Mais uma restrição relevante: o K2 não garante ordem de processamento entre workers, e chaves de mensagem ainda estão no roadmap. Se o seu caso depende de ordenação por partição como no Kafka, planeje com cuidado.

Preço do beta e o custo escondido do fan-out

Durante o beta, o uso é gratuito no plano pago dos Workers, com até 10 gigabytes de armazenamento por conta. Depois, a Cloudflare projeta 4 centavos de dólar por gigabyte produzido, 4 centavos por gigabyte consumido e 2 centavos por gigabyte por mês retido. São tarifas esperadas, sujeitas a mudança.

O detalhe fácil de perder, apontado na discussão no Hacker News: o consumo também cobra por gigabyte. Cada assinatura extra multiplica a conta de saída. Se você envia 1 gigabyte de pedidos para três serviços, o cálculo simples dá 4 centavos de entrada e 12 de saída. Fan-out é grátis no quadro branco, mas não na fatura.

Cloudflare K2 ou Kafka hoje: tabela de decisão

Você deve usar o K2 quando um consumidor pode esperar alguns segundos, mas não pode perder eventos. Configure a retenção para cobrir sua pior interrupção, torne cada handler seguro para rodar duas vezes e chegue result.success em todo envio. Se você precisa de entrega rápida ou mantém clientes Kafka, aguarde o tier express e o suporte planejado a clientes Kafka, ambos sem data no roadmap.

A tabela resume o estado em outubro de 2026, com números do beta público:

Dimensão	Cloudflare K2 (beta)	Kafka (disco local)
Armazenamento	Segmentos no R2	Réplicas entre brokers
Produção p99 (fornecedor)	~1 s	Menor, segundo a equipe do K2
Ponta a ponta p99 (comunidade)	7,5 s em teste individual	Não comparável diretamente
Clientes Kafka	Planejado, sem data	Nativos
Retenção	7 dias padrão, 30 dias máx.	Configurável sem teto documentado
Entrega	At-least-once, em lotes	At-least-once, com retries por mensagem

Um único teste comunitário e números de fornecedor não provam uma substituição geral. O que os dados suportam é mais modesto: para aplicativos em Workers que distribuem eventos a alguns serviços tolerantes a segundos de atraso, o K2 vale um teste no beta.

Perguntas frequentes sobre o Cloudflare K2

• O Cloudflare K2 substitui o Kafka? Não hoje. Ele tem a forma de um log append-only com leitores independentes, mas não aceita bibliotecas cliente do Kafka, e o suporte a esses clientes está apenas planejado no roadmap, sem data definida.

• Quanto tempo um evento fica disponível no K2? A retenção padrão é de 7 dias, configurável entre 1 hora e 30 dias. Se um consumidor ficar fora do ar por mais tempo que o período, os registros mais antigos são descartados antes de ele ler.

• Qual é a latência real do K2? A Cloudflare reporta cerca de 1 segundo de produção no p99. Um teste individual no Hacker News mediu 2,5 segundos no p95 e 7,5 segundos no p99 de entrega ponta a ponta no beta, então planeje com folga.

• O K2 é grátis? Durante o beta, o uso é gratuito no plano pago dos Workers, até 10 GB por conta. Depois, as tarifas esperadas são 4 centavos por GB produzido, 4 por GB consumido e 2 por GB retido por mês, sujeitas a mudança.

• Preciso tratar duplicatas no K2? Sim. A entrega é at-least-once e as reentregas acontecem por lote, então o mesmo registro pode chegar mais de uma vez. Use IDs idempotentes no consumidor e sempre verifique result.success ao produzir.

Source video