Cloudflare K2 Streams: event streams serverless para Workers e Pages

O que é o Cloudflare K2 Streams

O Cloudflare K2 Streams é um serviço de event streams serverless anunciado em outubro de 2026 pela Cloudflare. Ele permite que aplicações rodando em Workers e Pages publiquem e consumam eventos em tempo real, sem precisar provisionar filas, brokers ou servidores de mensageria.

O nome K2 segue a linha de nomes de montanhas que a Cloudflare usa para produtos de armazenamento e dados, como o R2 (object storage). A ideia central é simples: você pública eventos de um Worker, outro Worker consome - tudo dentro da rede global da Cloudflare, com latência baixa e sem gerenciar infraestrutura.

A solução chega num momento em que arquiteturas orientadas a eventos ganharam popularidade mas a complexidade de gerenciar Kafka, RabbitMQ ou SQS ainda assusta muitos times pequenos. O K2 mira exatamente esse público: equipes que já usam Workers e querem adicionar comunicação assíncrona sem sair do ecossistema Cloudflare.

Como funciona

O K2 Streams funciona com um modelo de producer-consumer baseado em streams imutáveis. Cada stream tem um nome único no seu namespace. Workers publicam eventos chamando a API do binding; outros Workers se inscrevem e recebem os eventos em ordem.

Por baixo, a Cloudflare usa sua infraestrutura distribuída globalmente para replicar e entregar os eventos. Você não configura partições, offsets ou replication factors - o serviço gerência isso automaticamente. A retenção padrão é configurável, com opções de minutos a dias dependendo do plano.

O binding é declarado no wrangler.toml do seu projeto. Em runtime, você acessa o stream pelo nome e chama métodos como .publish() para produzir e .consume() para receber eventos. A API é assíncrona e integra naturalmente com o modelo de async/await do Workers runtime.

Principais recursos

O K2 Streams chega com um conjunto de funcionalidades pensadas para o dia a dia de desenvolvimento com Workers:

• Publish/consume nativo no Workers runtime: sem SDK externo, sem chamada HTTP extra - o binding é resolvido em runtime diretamente.
• Retenção configurável: defina por quanto tempo os eventos ficam disponíveis, de 1 hora até 7 dias (dependendo do plano).
• Múltiplos consumidores: vários Workers podem consumir o mesmo stream de forma independente, cada um com seu próprio cursor.
• Integração com Durable Objects: você pode combinar K2 com Durable Objects para manter estado entre eventos de um mesmo usuário ou sessão.
• Métricas no dashboard: volume de eventos publicados, consumidos e latência média visíveis direto no painel da Cloudflare.

O diferencial maior em relação a soluções externas como Upstash Kafka ou Amazon Kinesis é a integração zero-config com o ecossistema Workers. Não há tokens, conexões TCP nem timeouts de cliente para gerenciar.

Como começar: acesso e configuração

O K2 Streams está disponível para contas Cloudflare com plano Workers Paid (US$ 5/mês). Para começar, você precisa do Wrangler CLI atualizado (versão 3.x ou superior) e uma conta com Workers habilitado.

Passo 1: Crie um stream via dashboard ou via Wrangler:

wrangler kv:namespace create meu-stream --type stream

Passo 2: Declare o binding no wrangler.toml:

[[k2_streams]]
binding = "MEU_STREAM"
stream_name = "meu-stream"

Passo 3: Use no código do Worker:

// Producer Worker
export default {
  async fetch(request, env) {
    await env.MEU_STREAM.publish({
      type: "user_signup",
      userId: "123",
      timestamp: Date.now()
    });
    return new Response("Evento publicado!");
  }
};

// Consumer Worker (no mesmo projeto ou projeto separado)
export default {
  async fetch(request, env) {
    const eventos = await env.MEU_STREAM.consume({ limit: 10 });
    return Response.json(eventos);
  }
};

Exemplo prático: auditoria de ações do usuário

Um caso clássico é registrar ações do usuário em tempo real sem bloquear a resposta HTTP. Imagine um e-commerce onde cada clique em produto deve ser registrado para analytics:

// Worker de produto (producer)
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const slug = url.searchParams.get("slug");

    // Pública evento sem await bloqueante
    const publicarEvento = env.ANALYTICS_STREAM.publish({
      event: "product_view",
      slug,
      userAgent: request.headers.get("user-agent"),
      ts: Date.now()
    });

    // Responde imediatamente, evento vai em background
    const produto = await buscarProduto(slug);
    await publicarEvento; // garante entrega antes do Worker encerrar
    return Response.json(produto);
  }
};

No lado do consumidor, um Worker separado agrega os eventos a cada minuto e salva totais no R2 ou D1. Você tem analytics em tempo real sem banco de dados transacional no caminho crítico.

Comparação com alternativas

Antes do K2, times usando Workers tinham algumas opções para comunicação assíncrona:

• Cloudflare Queues: filas com entrega garantida, retry e dead-letter queue. Ideal para jobs críticos onde perder uma mensagem é problemático. Não é um stream - não tem múltiplos consumidores independentes.
• Upstash Kafka: Kafka serverless com HTTP API, funciona bem com Workers. Mais maduro, mas requer conta externa e latência adicional de chamada HTTP.
• Amazon Kinesis: robusto e battle-tested, mas requer credenciais AWS, SDK externo e é caro para volumes baixos.
• Pub/Sub via Durable Objects: a solução manual que muitos times montaram antes do K2 - funciona, mas exige código de plumbing que o K2 elimina.

O K2 ganha em simplicidade de integração quando você já está no ecossistema Cloudflare. Se você precisa de garantias de entrega fortes ou já tem Kafka rodando, Queues ou Upstash Kafka são mais adequados.

Pontos positivos e limitações

Pontos positivos: integração nativa zero-config com Workers, latência baixa aproveitando a rede global da Cloudflare, não precisa gerenciar instâncias ou conexões, e preço incluído no Workers Paid para volumes moderados.

Limitações reais: está em beta, então a API pode mudar. A retenção máxima de 7 dias pode ser curta para casos de event sourcing de longo prazo. Não há replay de eventos arbitrários como no Kafka - o cursor avança e não volta. Sem suporte a mensagens binárias grandes (limite de tamanho por evento).

Casos de uso reais

O K2 Streams se encaixa bem em cenários específicos:

• Analytics de produto: registrar pageviews, cliques e conversões em tempo real sem banco de dados na rota crítica.
• Auditoria de segurança: logar todas as ações de admin (login, alteração de dados, deletar registro) em um stream imutável.
• Notificações em tempo real: um Worker pública evento de pedido confirmado, outro consome e dispara e-mail/WhatsApp.
• Sincronização entre Workers: coordenar múltiplos Workers sem Durable Object compartilhado, usando o stream como canal de comunicação.

Dicas e boas práticas

Vale a pena?

Se você já usa Cloudflare Workers e precisa de comunicação assíncrona entre Workers, o K2 Streams é a opção mais simples disponível hoje. Zero configuração, integração nativa e preço razoável para volumes médios.

Para quem está começando com Workers e quer adicionar eventos assíncronos ao projeto, este é o momento certo de explorar - ainda em beta, mas estável o suficiente para projetos pessoais e MVPs.

Quem não deve usar: times que precisam de garantias fortes de entrega (use Queues), retenção de anos (use R2 + D1), ou que já têm Kafka rodando bem (não vale a migração). Para todos os outros usando Workers, vale o teste agora.