Design de Sistemas para Editores Colaborativos: Google Docs e Figma em Profundidade

Você abre um Google Docs. Digita. Outra pessoa vê o texto aparecer em tempo real. Ninguém pensa em relógios, réplicas divergentes, rebase de operações ou undo corrompido.

Essa é a ilusão do produto. A realidade é um dos problemas mais complexos de sistemas distribuídos.

O problema real

Um editor colaborativo precisa fazer edições locais parecerem instantâneas (<16ms) e, ao mesmo tempo, produzir um documento compartilhado coerente com latência remota <150ms p95. Precisa aceitar redes instáveis, trabalho offline, rajadas de digitação, mudanças de permissão em tempo real, undo colaborativo, comentários ancorados, cursores de presença e histórico de versões.

E o pior: texto, rich text e canvas de design são problemas fundamentalmente diferentes. Um único algoritmo de merge não serve para todas as superfícies.

Os três modelos de merge

OT (Operational Transformation)

Servidor atribui ordem canônica. Clientes aplicam edições de forma otimista. Servidor transforma operações que chegam com base revisions antigas.

Quando usar: rich text centralizado, documentos empresariais com auditoria, baixo overhead de metadados. Google Docs segue esse modelo.

O risco: funções de transformação precisam estar corretas para cada par de operações. Rich text com tabelas, listas aninhadas e embeds cria muitos edge cases.

CRDT (Conflict-free Replicated Data Types)

Cada réplica aceita mudanças locais independentemente. Réplicas trocam updates e convergem automaticamente.

Quando usar: offline-first, sync peer-to-peer, multi-device local, semântica de branch/merge. Yjs e Automerge seguem essa linha.

O risco: overhead de metadados cresce, validação de updates pode ser difícil, rich text interleaving ainda pode gerar resultados ruins com algoritmo ingênuo.

Híbrido por propriedade (Canvas/Design)

Para editores tipo Figma, OT textual puro é o modelo mental errado. O estado central é um grafo de objetos. Edições concorrentes geralmente tocam propriedades diferentes.

Como funciona: IDs de objeto estáveis, mapas de propriedades, ordenação do servidor para escritas conflitantes na mesma propriedade, validação de invariantes de árvore no servidor.

Duas pessoas podem editar cor e posição do mesmo retângulo ao mesmo tempo sem conflito.

Arquitetura de alto nível

O sistema separa:

1. Plano de entrada: Load Balancer → Token Verifier → Realtime Gateway Fleet
2. Plano de colaboração: Session Directory → Document Worker → Merge Engine → Fanout Router
3. Plano de dados durável: Operation Log (append-only) → Snapshot Store → Metadata DB → Permission Store
4. Plano assíncrono: Event Bus → Search Indexer → History Builder → Audit Log

Princípio central

Mutações duráveis e awareness efêmero são separados. Presença (cursores, seleções, viewport) tem TTL de 15s e não polui o log de operações. Operações aceitas são append-only e imutáveis.

Protocolo de operações

Cada operação carrega:

• documentId — roteamento
• clientId + deviceId — identificação
• clientSeq — detecção de gaps e duplicatas
• opId — chave de idempotência
• baseRevision — estado que o cliente acreditava editar
• surface — texto, rich text, canvas
• payload — operação real

O servidor deduplica por opId, transforma/mescla, faz append no log durável, envia ack para o autor e faz fanout para colaboradores.

Regra crítica: ack só depois de append durável. Se o servidor confirma antes de gravar, uma queda pode perder trabalho confirmado.

Offline e reconexão

O design suporta offline forte:

1. Cliente edita offline, acumula operações locais em IndexedDB/SQLite
2. Na reconexão, envia lastSeenRevision
3. Servidor envia operações remotas de catch-up
4. Cliente faz rebase (OT) ou merge (CRDT) das operações locais
5. Envia operações pendentes ao servidor
6. Se transformação falhar, marca conflito e pede decisão do usuário

UX de conflito importa: overwrites silenciosos destroem confiança. Quando intenção não pode ser preservada automaticamente, mostre caminho claro de recuperação.

Permissões em tempo real

Permissões não são checadas só ao abrir documento. Cada mutação verifica:

• Usuário ainda tem write access
• Documento não está arquivado
• Objeto não está locked
• Política do workspace permite operação

Quando permissões mudam durante sessão ativa:

1. acl_version incrementa
2. Sessões ativas atualizam capabilities
3. Usuários que perderam leitura são desconectados
4. Operações pendentes não autorizadas são rejeitadas

Fanout de documento quente

Para documentos normais (3 colaboradores), o worker transmite direto. Para documentos quentes (1.000 pessoas):

• Worker serializa operações
• Publica em tópico do documento
• Workers de subscription locais aos gateways fazem fanout
• Clientes lentos recebem batches ou são forçados a resync

Um documento de all-hands com 1.000 pessoas e 10 digitadores ativos gera ~50.000 mensagens/s para um único documento.

10 anti-patterns para evitar

1. Enviar documento inteiro a cada edição
2. Usar last-write-wins para texto denso
3. Colocar presença no log durável
4. Confirmar antes do append durável
5. Ignorar mudanças de permissão depois do join
6. Tratar comentários como offsets simples
7. Deixar um worker fazer fanout para milhares de sockets
8. Pular versionamento de schema de operação
9. Compactar sem respeitar semântica de produto
10. Esconder resolução de conflito

Para entrevistas de System Design

O fluxo forte em 10 minutos:

1. Clarifique a superfície (texto, canvas, misto)
2. Defina colaboração (realtime, offline, presença)
3. Estime conexões, ops/s, fanout e armazenamento
4. Desenhe plano de controle vs plano realtime
5. Escolha modelo de merge e explique por quê
6. Detalhe protocolo de operações e idempotência
7. Explique snapshots, logs e recuperação
8. Cubra permissões e revogação
9. Adicione confiabilidade e observabilidade
10. Nomeie anti-patterns e trade-offs

---

Artigo completo com diagramas de sequência, tabelas de decisão, exemplos de payload, estimativas de capacidade e referências:

https://lemon.dev.br/pt/blog/collaborative-editor-system-design

Se você trabalha com sistemas distribuídos ou tem entrevista de system design pela frente, esse é provavelmente o guia mais completo em português sobre o tema.