CRDT em produção: convergir não significa estar correto

CRDT em produção resolve uma parte difícil da sincronização: fazer réplicas concorrentes chegarem ao mesmo estado. A armadilha é tratar isso como se fosse a mesma coisa que preservar intenção, regra de negócio e custo operacional aceitável.

Imagine duas pessoas editando offline o mesmo documento. Uma alteração gera AB, outra gera BC. Se o sistema usa Last Write Wins para a propriedade inteira, as réplicas podem concordar em AB ou em BC, mas não em ABC. A convergência existe. O trabalho de alguém desaparece.

Essa é a pergunta que importa para arquitetura: quando duas mudanças válidas se encontram, qual resultado o domínio aceita?

CRDT em produção resolve merge concorrente?

Um CRDT é um tipo de dado construído com regras de combinação embutidas. Quando as réplicas recebem o mesmo conjunto de atualizações, essas regras fazem todas convergirem para o mesmo estado, sem exigir uma ordem total central para cada escrita.

Essa propriedade é útil em edição colaborativa, trabalho offline, replicação geográfica e sistemas que não podem depender de coordenação síncrona a cada alteração. Mas ela tem condições. As atualizações ainda precisam chegar. A aplicação ainda precisa autenticar, autorizar, persistir, reconectar, deduplicar e lidar com falhas de entrega.

Em texto colaborativo, o problema aparece rápido. “Inserir na posição 5” não é uma instrução estável quando outra réplica inseriu caracteres antes da mesma posição. Por isso algoritmos de sequência usam alguma forma de identidade ou ordenação lógica. O índice visível na tela não basta.

WebSocket vs CRDT: qual problema cada um resolve?

WebSocket resolve transporte bidirecional. Ele abre um canal para mensagens circularem com baixa latência. Isso não define a semântica de merge.

Se duas réplicas produziram estados concorrentes, a conexão apenas entrega mensagens. Quem decide se o resultado será AB, BC, ABC, uma interleaving estranha ou uma rejeição explícita é o modelo de dados e a regra de domínio. Confundir transporte com merge costuma produzir sistemas que parecem funcionar na demo e quebram quando aparecem offline, reconexão, duplicação de mensagens ou alterações simultâneas no mesmo campo.

Também existe diferença entre famílias de CRDT. Implementações baseadas em estado e baseadas em operações colocam requisitos em lugares diferentes. Em muitos desenhos, disseminar operações reduz payload, mas empurra mais responsabilidade para a camada de entrega: causalidade, persistência, idempotência e recuperação precisam deixar rastro.

Quando CRDT vale a pena e quando vira custo?

CRDT tende a valer a pena quando o produto realmente precisa aceitar concorrência, offline, alta disponibilidade sob falha de rede ou replicação geográfica com baixa coordenação. Quanto menos esses requisitos existem, mais difícil fica justificar a conta.

Essa conta não é abstrata. Convergência costuma cobrar metadados: identificadores, informação causal, histórico, tombstones em alguns algoritmos ou trabalho posterior de compactação. Não existe um percentual universal. O custo depende do tipo de dado, do padrão de edição, do número de réplicas e do algoritmo escolhido.

JupyterLab é um caso real instrutivo: usa Yjs para colaboração em tempo real, mas ainda mantém persistência e reconexão como camadas separadas no ambiente do Jupyter Server. O CRDT participa do modelo colaborativo. Ele não substitui banco, protocolo e operação.

O contraponto também é útil. A Figma documentou uma arquitetura com servidor como autoridade central para ordenar e validar mudanças, inspirada em ideias de CRDT, mas não um CRDT puro. Isso simplificou parte do merge, mas trouxe outra conta: disponibilidade, durabilidade e recuperação. No desenho antigo, checkpoints podiam deixar uma janela de perda de trabalho, depois reduzida com write-ahead log.

Por que convergir não garante correção do domínio?

Convergência responde a uma pergunta técnica: todas as réplicas chegaram ao mesmo estado? Correção responde outra: esse estado respeita a intenção do usuário e os invariantes do domínio?

Duas réplicas podem vender o mesmo assento offline e depois convergir para um estado consistente entre elas. O sistema concordou consigo mesmo, mas violou a regra de negócio. Em outros domínios, duas frases digitadas ao mesmo tempo podem convergir para um texto intercalado e ilegível. Tecnicamente igual em todas as cópias. Ruim para o humano.

A decisão pragmática não é “usar CRDT” ou “usar servidor central” como posição ideológica. É mapear quais operações do domínio aceitam merge automático e quais exigem reserva, coordenação, particionamento de direitos ou rejeição posterior. Estrutura de dados ajuda. Arquitetura ainda decide o que é correto.

Referências

Assista ao vídeo completo no YouTube →

Leia também