Abra um documento do Google Docs com um colega, os dois digitando ao mesmo tempo em parágrafos diferentes, e nada trava, nada some, nada gera aquela mensagem irritante de “conflito de versão”. Mova um retângulo no Figma enquanto outra pessoa da equipe redimensiona o mesmo objeto, e as duas mudanças se acomodam sem que o arquivo corrompa. Pelos padrões da computação distribuída — a área que estuda como máquinas diferentes trocam informação sem travar tudo — isso não deveria ser trivial. Duas cópias do mesmo dado, editadas ao mesmo tempo, em lugares diferentes, sem ninguém dando a palavra final em tempo real: a receita clássica para um desastre de sincronização. E, no entanto, funciona todo dia, para milhões de pessoas, sem que ninguém perceba a engenharia por trás.
Uma parte importante dessa mágica tem nome, definição matemática e um artigo de pesquisa fundador: CRDT, sigla para Conflict-free Replicated Data Type — em português, algo como “tipo de dado replicado livre de conflitos”. É uma família de estruturas de dados desenhada para uma promessa específica: não importa em que ordem as edições cheguem a cada cópia, todas as cópias terminam exatamente no mesmo estado, sem precisar perguntar a um servidor central “quem manda aqui”.
O problema que a internet finge que não existe
Quando um aplicativo é “só” um cliente conversando com um servidor, resolver conflito é fácil: o servidor é o juiz. Ele recebe os pedidos, decide a ordem, e todo mundo aceita o veredito. O problema aparece quando essa arbitragem central não pode — ou não deve — existir o tempo todo.
Pense numa lista de compras compartilhada entre duas pessoas, cada uma no celular, uma delas no metrô sem sinal. As duas mexem na lista ao mesmo tempo: uma risca “leite”, a outra adiciona “pão”. Quando o sinal volta, os dois celulares precisam concordar sobre o resultado final sem que um deles simplesmente sobrescreva o outro. Se o aplicativo apenas manda “a versão mais recente vence”, a edição de quem estava sem internet pode desaparecer inteira — é exatamente esse tipo de perda de dado silenciosa que motivou boa parte da pesquisa em sistemas distribuídos nas últimas duas décadas.
O mesmo desafio, em escala muito maior, aparece em editores colaborativos como Figma ou Google Docs: dezenas de cursores diferentes, cada um mudando um pedaço do mesmo documento, ao mesmo tempo, com latências de rede diferentes para cada pessoa. Não dá para pausar o mundo e perguntar “quem editou primeiro?” — a resposta muda dependendo de qual relógio você escolhe confiar, e relógios de máquinas diferentes nunca estão perfeitamente sincronizados.
A ideia central: convergência garantida por matemática, não por sorte
A resposta que os CRDTs propõem é elegante: em vez de tentar decidir qual edição “chegou primeiro”, as operações de edição são projetadas para que a ordem simplesmente não importe. Se o resultado final é sempre o mesmo, não importa a sequência em que as mudanças forem aplicadas, o problema de coordenação desaparece — cada cópia pode processar as edições na ordem em que elas chegam, mesmo que seja uma ordem diferente em cada dispositivo, e todas vão convergir sozinhas para o mesmo estado.
Essa garantia não é uma promessa vaga de marketing técnico: é consequência de três propriedades matemáticas que as operações precisam satisfazer.
A primeira é a comutatividade: fazer A e depois B dá o mesmo resultado que fazer B e depois A. É a mesma lógica da soma na aritmética básica — 3 + 5 é igual a 5 + 3. Se as operações de edição de um CRDT tiverem essa propriedade, a ordem de chegada deixa de ser um problema.
A segunda é a associatividade: agrupar as operações de formas diferentes também não muda o resultado — (A + B) + C é igual a A + (B + C). Isso importa porque, numa rede real, os pacotes de dados podem chegar em lotes diferentes dependendo do caminho que percorreram.
A terceira, e talvez a mais contraintuitiva, é a idempotência: aplicar a mesma operação duas vezes tem exatamente o mesmo efeito que aplicar uma vez só. Isso é crucial porque redes de computadores duplicam mensagens com uma certa frequência — um pacote pode ser reenviado porque a confirmação de recebimento se perdeu, mesmo que a mensagem original tenha chegado. Um sistema ingênuo que apenas “soma 1 ao contador” a cada mensagem recebida quebra nesse cenário: uma mensagem duplicada infla o contador errado. Um CRDT bem desenhado é imune a isso por construção.
Exemplos concretos: como isso vira código de verdade
O exemplo mais citado é o contador que só cresce (na literatura, “G-Counter”, de grow-only counter). Em vez de cada dispositivo guardar um único número e tentar somar diretamente — o que geraria conflito se dois dispositivos somarem ao mesmo tempo —, cada réplica mantém seu próprio contador parcial. O dispositivo A soma no contador de A, o dispositivo B soma no contador de B. O valor total, visível para qualquer um, é sempre a soma de todos os contadores parciais. Juntar dois contadores desse tipo significa pegar o maior valor registrado para cada dispositivo — uma operação que é comutativa, associativa e idempotente ao mesmo tempo, então pode ser repetida, reordenada ou aplicada em qualquer sequência sem gerar erro.
Outro exemplo é o conjunto que só cresce (um “grupo” de itens onde só se pode adicionar, nunca remover). Adicionar o mesmo item duas vezes não muda nada — um conjunto matemático, por definição, não tem duplicatas —, e a ordem de adição dos itens é irrelevante para o resultado final: o conjunto {leite, pão} é idêntico não importa se “leite” ou “pão” foi adicionado primeiro. Estruturas mais sofisticadas — usadas de fato em produtos como listas de tarefas, textos colaborativos e até desenhos vetoriais — combinam essa ideia com marcações de tempo e identificadores únicos por operação para permitir também remoções e reordenações sem perder a garantia de convergência.
A pesquisa que deu nome e formalização a essa família de estruturas é o relatório técnico “Conflict-free Replicated Data Types”, de Marc Shapiro (INRIA e LIP6, Paris), Nuno Preguiça (Universidade Nova de Lisboa), Carlos Baquero (Universidade do Minho) e Marek Zawirski (INRIA e UPMC), publicado pelo INRIA como Rapport de recherche n° 7687 em julho de 2011, com uma revisão em agosto do mesmo ano. É esse documento que organiza formalmente as duas grandes famílias de CRDTs — as baseadas em estado, que sincronizam trocando o estado inteiro da réplica, e as baseadas em operação, que sincronizam trocando apenas as operações realizadas — e prova matematicamente por que ambas garantem convergência.
Onde isso aparece na sua tela, de verdade
Aqui vale uma correção importante, porque é comum a explicação popular simplificar demais: o Figma não usa um CRDT “de livro-texto”. Segundo o próprio time de engenharia da empresa, na publicação oficial “How Figma’s multiplayer technology works”, o sistema deles foi inspirado em CRDTs, mas simplificado deliberadamente porque a arquitetura do Figma não é totalmente descentralizada — ela ainda depende de um servidor central que arbitra a ordem final dos eventos. Os CRDTs “de verdade”, como definidos por Shapiro e colegas, foram desenhados justamente para cenários sem nenhuma autoridade central. O Figma também descartou explicitamente outra técnica concorrente e mais antiga, chamada Operational Transformation (OT) — usada, por exemplo, no Google Docs —, por considerá-la complexa demais para o problema deles. O resultado é um sistema próprio, no qual cada propriedade de cada objeto (a posição de um retângulo, a cor de um texto) guarda o último valor recebido pelo servidor — algo parecido com um tipo específico e mais simples de CRDT chamado “registrador de última escrita vence” (last-writer-wins register), mas operando dentro de uma arquitetura centralizada, não distribuída. Uma limitação real e reconhecida por eles: como a sincronização acontece propriedade por propriedade, duas pessoas digitando ao mesmo tempo no mesmo campo de texto podem ver o resultado final “cortado” de forma inesperada — o sistema não foi pensado para edição concorrente de texto corrido, diferente do Google Docs.
Onde os CRDTs “de livro-texto” aparecem com mais fidelidade é no movimento de software chamado local-first — aplicativos que tratam o dispositivo do usuário, e não o servidor na nuvem, como a cópia principal e definitiva dos dados, sincronizando com outros dispositivos quando a rede permite. O principal nome por trás dessa ideia é Martin Kleppmann, pesquisador da Universidade de Cambridge, coautor do artigo de referência “Local-First Software: You Own Your Data, in Spite of the Cloud” (com Adam Wiggins, Peter van Hardenberg e Mark McGranaghan, publicado na conferência Onward! da ACM em 2019), que descreve os CRDTs como uma tecnologia fundacional para viabilizar esse tipo de aplicativo. Kleppmann também é autor principal, junto com Alastair Beresford, do artigo técnico “A Conflict-Free Replicated JSON Datatype” (IEEE Transactions on Parallel and Distributed Systems, 2017), que descreve um CRDT capaz de representar estruturas de dados JSON inteiras — não só contadores ou conjuntos simples, mas documentos aninhados, com listas, objetos e texto. Esse trabalho é a base teórica por trás do Automerge, biblioteca de código aberto da qual Kleppmann é autor principal, desenvolvida em parceria com o laboratório de pesquisa Ink & Switch, que qualquer desenvolvedor pode usar hoje para construir aplicativos que sincronizam dados entre dispositivos sem depender de um servidor sempre disponível — exatamente o caso da lista de compras compartilhada que continua funcionando mesmo com um dos celulares no metrô, sem sinal.
Vale um adendo sobre o próprio termo: uma busca por conteúdo em português sobre o assunto mostra que a cobertura existente é escassa e, quando existe, tende a ser técnica — voltada a programadores, com jargão de sistemas distribuídos e pouca preocupação em explicar a ideia para quem não escreve código. Isso não é surpresa: CRDTs nasceram e circulam majoritariamente em círculos de engenharia de software, apesar de explicarem um fenômeno que qualquer pessoa que já usou uma planilha compartilhada já sentiu na pele.
Fontes
Shapiro, M.; Preguiça, N.; Baquero, C.; Zawirski, M. Conflict-free Replicated Data Types. Rapport de recherche n° 7687, INRIA, julho de 2011 (revisado em agosto de 2011). Disponível em: inria.hal.science/inria-00609399.
crdt.tech — site de referência acadêmica sobre CRDTs, mantido por Martin Kleppmann, Annette Bieniusa e Marc Shapiro.
Figma Engineering. How Figma’s multiplayer technology works. Figma Blog. Disponível em: figma.com/blog/how-figmas-multiplayer-technology-works.
Kleppmann, M.; Wiggins, A.; van Hardenberg, P.; McGranaghan, M. Local-First Software: You Own Your Data, in Spite of the Cloud. Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (Onward! 2019).
Kleppmann, M.; Beresford, A. R. A Conflict-Free Replicated JSON Datatype. IEEE Transactions on Parallel and Distributed Systems, v. 28, n. 10, p. 2733–2746, 2017.
Automerge — biblioteca de código aberto para CRDTs, automerge.org.