Uma visão geral da plataforma Workers
O Cloudflare Workers é um FaaS baseado em V8 Isolate que, em abril de 2026, implanta o mesmo código instantaneamente em mais de 330 PoPs ao redor do mundo. O cold start é praticamente zero (abaixo de 5ms na maioria das requisições), mas ao contrário do AWS Lambda — que usa containers —, a restrição de usar Isolates torna os módulos nativos do Node.js e I/O bloqueante de longa duração fundamentalmente incompatíveis. O nodejs_compat_v2, que entrou em disponibilidade geral no segundo semestre de 2025, melhorou significativamente a compatibilidade com fs, crypto e stream — mas ainda é possível colidir com o limite de sub-requisições (1.000) ou a restrição de CPU time (5 minutos no plano pago) se você escrever sem entender "o modo de trabalhar dos Isolates".
O Workers realmente brilha quando lógica stateful é combinada com Durable Objects. Um Durable Object (DO) é um "ator globalmente único, single-thread e com consistência forte", onde as requisições para o mesmo DO são sempre serializadas. Esse modelo foi projetado como "substituto do mutex no edge", permitindo que casos de uso tradicionais — como rate limiting por usuário, sinalização por sala de reunião ou reserva de estoque por ID de transação — implementados com advisory lock do Redis ou Postgres sejam resolvidos localmente sem RTT.
O modelo de transação dos Durable Objects
O armazenamento persistente do DO oferece internamente uma storage API baseada em SQLite. Desde que o SQLite-backed DO foi liberado para todos os planos em 2025, é possível armazenar até 10GB de dados relacionais por DO e executar múltiplos put/delete atomicamente dentro de um callback transaction(). O ponto crucial é que o DO contém um "input gate" e um "output gate". O input gate bloqueia novas requisições enquanto aguarda writes na storage durante o processamento de uma requisição, e o output gate adia a resposta fetch até que os writes na storage sejam persistidos. Com esse duplo gate, a integridade nunca é quebrada mesmo escrevendo async/await livremente no código da aplicação.
```typescript export class InventoryDO { state: DurableObjectState; constructor(state: DurableObjectState) { this.state = state; } async fetch(req: Request) { const { sku, qty } = await req.json<{ sku: string; qty: number }>(); return await this.state.storage.transaction(async (tx) => { const current = (await tx.get<number>(sku)) ?? 0; if (current < qty) return new Response("oos", { status: 409 }); await tx.put(sku, current - qty); return new Response(JSON.stringify({ remain: current - qty })); }); } } ```
Um erro comum ao usar DOs de forma actor-like é o design de "processar todos os tenants em um único DO". Quando um DO se torna um hotspot, o PoP fica fixo, impondo alta latência a usuários geograficamente distantes. A solução correta é concatenar "tenant ID + resource ID" usando idFromName() para fazer sharding, garantindo que as escritas tenham localidade geográfica. As leituras podem ser servidas com O(1) a partir de replica DOs (disponíveis desde 2025) com réplicas assíncronas.
Uso adequado de Workers KV, Hyperdrive e D1
As três camadas de dados têm propósitos claramente distintos. Workers KV é um armazenamento otimizado para leitura com consistência eventual, adequado para configurações e metadados que tolerem propagação de até 60 segundos. O atraso de propagação de PUT varia de segundos a 60 segundos; as leituras retornam em 1ms a partir do cache local do PoP. Hyperdrive é um connection pooler para Postgres/MySQL externos que reutiliza conexões TCP ao origin e faz cache de resultados de query no PoP — a opção mais realista como primeiro passo para organizações com ativos RDB existentes migrando para o edge. D1 é o banco de dados SQLite proprietário da Cloudflare: as read replicas entraram em disponibilidade geral em 2025, permitindo uma topologia estilo PostgreSQL onde escritas vão para o primário e leituras para a réplica mais próxima.
O critério de escolha se decompõe em "frequência de escritas" e "requisitos de consistência". Para mais de 1.000 escritas por segundo com isolamento por tenant: DO. Para poucas escritas globais + leituras geograficamente distribuídas: D1. Se já existe um banco externo: Hyperdrive. Para distribuição de configurações baseada em TTL: KV. O R2 (armazenamento de objetos compatível com S3) é ortogonal a todos esses e é usado para streaming de vídeo, backup e data lake, aproveitando o egress gratuito.
Workers AI e roteamento de inferência
Desde a disponibilidade geral do Workers AI em 2024, é possível chamar modelos OSS principais como Llama 3.3 70B, Mistral Large 2, GPT-OSS-120B e Qwen 3 com cobrança por uso. Em 2026, é possível rotear OpenAI, Anthropic e Google via BYOK por uma única API (AI Gateway), com cache de resposta, retry e rate limiting gerenciados de forma unificada no lado do Workers. Os logs do AI Gateway fluem para o Analytics Engine, permitindo consultar o custo de tokens por prompt via SQL.
O padrão para otimização de latência é o híbrido "inferência pequena e de julgamento no Workers AI local, raciocínio complexo no LLM externo". Por exemplo, julgamento de bot, classificação NSFW e detecção de idioma são resolvidos com Llama Guard/Llama-3 8B do Workers AI, e apenas quando o resultado é "incerto" é que se faz o escalamento para Claude ou GPT. Confirmamos vários casos em que esse roteamento em dois estágios reduziu os custos em 70%.
Otimização de hot path com bindings Rust + WASM
TypeScript em 5ms, Rust + WASM em 0,8ms. Essa diferença começa a impactar o orçamento de CPU time quando se trata de 100.000 requisições por segundo. O workers-rs (crate Rust) compila para o runtime do Workers com a macro `#[event(fetch)]` e acessa APIs JS (fetch, crypto, R2) via wasm-bindgen. Reescrever parse de JSON pesado em gateways de API, validação de HMAC, validação de JWT ou redimensionamento de imagem em Rust gera um grande efeito de redução de custos.
```rust use worker::*; #[event(fetch)] async fn main(req: Request, env: Env, _ctx: Context) -> Result<Response> { let body: serde_json::Value = req.json().await?; let signature = req.headers().get("x-signature")?.unwrap_or_default(); if !verify_hmac(&body, &signature, &env.secret("HMAC_KEY")?.to_string()) { return Response::error("invalid signature", 401); } Response::ok("ok") } ```
Ponto de atenção: o tamanho do módulo WASM deve ser mantido abaixo de 10MB. A combinação de wasm-opt -Oz e wee_alloc pode reduzir o tamanho efetivo à metade. O custo de inicialização é praticamente ignorável com a reutilização de Isolate, mas como a primeira compilação leva de 20 a 50ms, em PoPs com tráfego extremamente baixo pode ocorrer um fenômeno inverso onde TypeScript é mais rápido. Benchmarks devem ser realizados nos PoPs de produção — isso é indispensável.
Padrões para construção de máquinas de estado globais
A combinação de WebSocket Hibernation + Durable Objects tornou-se o padrão para edição colaborativa em tempo real, sinalização de live streaming e orquestração de dispositivos IoT. A Hibernation API permite liberar memória mantendo as conexões WebSocket abertas, e a cobrança do DO ocorre apenas durante o "tempo ativo". Uma estrutura de custos que se mantém em alguns milhares de dólares por mês mesmo com 1 milhão de conexões ativas cria a motivação para construir serviços similares ao Ably ou Pusher de forma proprietária.
O ponto-chave de design é tratar o DO como "um único nó da máquina de estado". As transições de estado são feitas atualizando a state version com CAS dentro de storage.transaction, e eventos externos são disparados via Queues. Transações compensatórias em caso de falha podem ser executadas de forma atrasada com a API alarm(). Com isso, é possível montar um padrão saga que começa e termina no edge com baixa latência. A arquitetura que não retorna ao origin é o principal campo de batalha do design de sistemas distribuídos em 2026.