Durable Objects: Estado e Consistência Forte no Edge

10 Abr, 2026

Escalar estado em sistemas distribuídos é, historicamente, um exercício de paciência e trade-offs dolorosos. Se você já tentou construir um chat em tempo real ou um sistema multi-player, sabe do que estou falando: race conditions, latência de bancos de dados centralizados e a complexidade de gerenciar locks distribuídos com Redis.

Recentemente, ao trabalhar em projetos que exigiam um isolamento rígido de sessão e baixa latência, redescobri o poder dos Cloudflare Durable Objects (DO). Eles não são apenas mais um storage no Edge; eles oferecem uma camada de coordenação e storage fortemente consistente que simplifica radicalmente a arquitetura de sistemas stateful.

O problema da concorrência "tradicional"

Em uma arquitetura serverless comum (como AWS Lambda ou os próprios Cloudflare Workers padrão), cada requisição é isolada. Se dois usuários tentam atualizar o mesmo saldo ou enviar uma mensagem na mesma sala ao mesmo tempo, você precisa de um coordenador externo. Normalmente, isso significa:

1. Abrir uma conexão com um banco/Redis.
2. Tentar adquirir um lock.
3. Ler o estado, modificar e salvar.
4. Liberar o lock.

Isso é lento, propenso a falhas e caro em termos de latência. O Durable Objects inverte essa lógica ao fornecer um ambiente stateful onde a consistência é garantida pelo runtime. No entanto, é vital planejar o sharding: uma única instância de DO suporta cerca de ~1.000 requisições por segundo para operações simples; escalabilidade massiva exige distribuir o trabalho entre múltiplos objetos.

O que torna os Durable Objects únicos?

A grande mágica do DO é a combinação de três características fundamentais:

1. Unicidade e Identidade: Cada objeto tem um ID único. O Cloudflare garante que exista apenas uma única instância ativa para aquele ID no mundo inteiro em um dado momento.
2. Coordenação Single-threaded e Output Gates: Todas as requisições destinadas àquele ID específico chegam à mesma instância. O runtime garante a consistência através de Output Gates: o cliente só recebe a confirmação de sucesso após a persistência física no storage. Isso permite o modelo "Easy, Fast, Correct" sem complexidade extra. No entanto, é importante notar que operações assíncronas (como I/O externo) permitem o interleaving de requisições; a execução não é estritamente serializada se houver esperas assíncronas.
   • Exemplo Prático: Imagine uma sessão com um contador de créditos. Se a lógica faz "ler saldo -> chamar API externa -> atualizar saldo", duas requisições podem ler o mesmo valor antes da atualização final acontecer. O Durable Object continua sendo o lugar certo para coordenar esse estado, mas a ordem das operações ainda precisa ser desenhada com cuidado.
3. Storage Privado e Transacional: O objeto possui seu próprio storage de estado, que é transacional e fortemente consistente. O caminho moderno e recomendado para novos projetos é o storage baseado em SQLite, que permite inclusive buscas complexas dentro do escopo do objeto. Diferente de outros storages distribuídos, aqui o dado é acessado com alta localidade pela instância de execução.

Nota sobre Durabilidade: O estado mantido apenas em memória RAM não é durável. Como o runtime pode hibernar ou sofrer evicção da instância a qualquer momento para otimizar recursos, qualquer estado crítico que precise sobreviver a reinícios deve ser persistido explicitamente no storage do objeto.

System Design na prática: O caso do Chat Isolado

Imagine que você está construindo uma plataforma de chat com milhares de salas independentes. Em um design tradicional, você teria que lidar com balanceadores de carga, sessões de WebSockets espalhadas por vários servidores e um Pub/Sub centralizado para sincronizar tudo.

Com Durable Objects, o design simplifica para:

• Cada Sala de Chat é um Durable Object único.
• Quando um usuário se conecta, o Worker roteia a requisição para a instância daquela sala. Essa instância roda em uma única localização geográfica, normalmente próxima do ponto de acesso inicial ou conforme estratégia de localização, facilitando a coordenação local por entidade.
• O DO pode manter a lista de usuários e estados transientes em memória RAM para máxima performance, mas deve persistir explicitamente no storage o que for vital para reconstruir a sala após um eventual reinício ou hibernação.

Minha experiência: Multi-tenancy e Agentes de IA

Usei essa arquitetura em dois projetos críticos recentemente: a Orquestração de Robôs para Crédito e o Agente de IA para Qualificação de Vendas.

No projeto de orquestração, precisávamos garantir que cada robô e cada cliente tivessem um isolamento total de estado. O Durable Object serviu como o "cérebro" de cada sessão, garantindo que comandos não se sobrepusessem e que o estado do robô fosse consistente, mesmo com instabilidades na rede.

Já no Agente de IA, o DO foi fundamental para manter o contexto da conversa no WhatsApp de forma atômica. Enquanto a IA processa a resposta, o DO garante que novas mensagens do mesmo lead não gerem condições de corrida ou respostas duplicadas, segurando o estado da sessão de forma extremamente eficiente.

Quando NÃO usar Durable Objects

Apesar do poder, essa abordagem não é uma "bala de prata". Evite-o se você precisar de:

• Agregações Globais: Se o requisito for contar algo em todos os objetos simultaneamente ou fazer analytics global, um banco de dados relacional ou OLAP centralizado será muito mais eficiente.
• Busca em Larga Escala: O storage é privado ao objeto. Buscar dados entre milhares de instâncias exige uma arquitetura de indexação externa complexa.
• Coordenação Excessiva: Se muitos objetos precisam "falar" entre si o tempo todo, a latência de rede entre instâncias pode anular os ganhos de performance.

A faca de dois gumes: Trade-offs e Limitações

Nem tudo são flores. Ao escolher essa arquitetura, você está trocando um tipo de complexidade por outro.

• Linearizabilidade Global: O Cloudflare garante consistência forte dentro de uma instância de Durable Object. No entanto, se o seu sistema depende de uma visão global linearizável de todos os objetos (ex: "quantos usuários existem em todas as 5.000 salas no exato milissegundo X?"), o DO não é a ferramenta certa.
• Indexação e Busca: Como os dados estão espalhados em milhares de instâncias no Edge, você perde a capacidade de fazer queries complexas ou agregações globais que um banco SQL tradicional permitiria. Indexar esses dados requer uma estratégia à parte (como exportar eventos para um banco analítico ou data lake).
• Falta de Centralização: O isolamento é a maior força e, ao mesmo tempo, a maior dor de cabeça. Se você precisa de coordenação entre múltiplos DOs de forma frequente, o design pode se tornar complexo e a latência pode voltar a ser um problema.

Dicas para quem está começando

Se você vai seguir por esse caminho, aqui estão alguns aprendizados práticos:

• TypeScript por padrão: O ecossistema de Workers é nativamente Typescript. Use as definições de tipo para os bindings do DO, facilitando muito a chamada de métodos remotos entre o Worker e o Object.
• Hono no Edge: Para gerenciar rotas e lógica de middleware, o Hono tem se mostrado uma das opções mais ergonômicas e performáticas no ecossistema de Workers.
• Cuidado com dependências Node: Lembre-se que você não está em um ambiente Node.js completo. Algumas bibliotecas que dependem de APIs nativas do Node não vão funcionar. Priorize pacotes que suportam Web Standards ou que sejam "Edge-ready".

Conclusão

Cloudflare Durable Objects oferecem um modelo elegante para coordenação, tempo real e multi-tenancy no Edge. Ao fornecer consistência forte onde as arquiteturas serverless tradicionais falham, eles se tornam uma ferramenta indispensável no arsenal de System Design moderno, desde que você esteja ciente dos modelos de concorrência assíncrona e das estratégias de persistência.

Se você tem um problema onde o estado precisa de consistência forte e uma localização otimizada para o ponto de coordenação, talvez seja hora de parar de brigar com locks distribuídos e experimentar o que o Edge pode oferecer de fato.