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

Resumo: Um design de sistema de nível produção para editores colaborativos, cobrindo sessões em tempo real, trade-offs entre OT e CRDT, sincronização offline, logs de operações, snapshots, permissões, histórico de versões, confiabilidade, segurança, observabilidade e raciocínio de entrevista para produtos no estilo Google Docs e Figma.

Publicado: Fevereiro 2026 Tempo de leitura: 120 minutos Palavras-chave: #SystemDesign #EditorColaborativo #GoogleDocs #Figma #OperationalTransformation #CRDT #WebSocket #SistemasDistribuidos #Escalabilidade #EntrevistaTecnica

Um editor colaborativo parece simples quando funciona. Duas pessoas abrem o mesmo documento. Uma digita. A outra vê o texto se mover. Uma terceira comenta. Uma quarta arrasta um frame em um canvas de design. Ninguém pensa em relógios, retries, réplicas divergentes, rebase de operações, verificação de acesso, fanout, snapshots ou undo corrompido. Essa é a ilusão do produto. A realidade do sistema é mais difícil. Um editor colaborativo precisa fazer edições locais parecerem instantâneas e, ao mesmo tempo, produzir um documento compartilhado coerente. Ele precisa aceitar redes instáveis, trabalho offline, rajadas de digitação, mudanças de permissão, undo, comentários, cursores, assets e histórico longo. Ele também precisa suportar modelos de edição diferentes. Texto e rich text se comportam de forma diferente de canvas e design. Editores no estilo Google Docs geralmente dependem de operações ordenadas sobre caracteres, parágrafos e marcações. Editores no estilo Figma geralmente dependem de árvores de objetos, propriedades, ordenação de layers, assets e estado de canvas. Um único algoritmo de merge não serve para todas as superfícies. Este guia desenha um editor colaborativo de produção que suporta:

• um editor de documentos parecido com Google Docs,
• um editor de canvas/design parecido com Figma,
• multiplayer em tempo real,
• edições offline,
• histórico durável,
• permissões fortes,
• monitoramento operacional,
• raciocínio de trade-offs para entrevistas. Os números deste artigo são premissas para design de sistemas. Eles não são afirmações sobre tráfego real de Google Docs, Figma, Automerge ou Yjs.

Sumário

• Análise de Requisitos
• Estimativas de Capacidade
• Arquitetura de Alto Nível
• Design de APIs
• Modelagem de Dados
• Modelos de Edição: Texto, Rich Text e Canvas
• Sessões de Documento e Fanout em Tempo Real
• Protocolo de Operações e Idempotência
• OT vs CRDT: Escolhendo o Modelo de Merge
• Design OT com Servidor Autoritativo
• Design com CRDT Puro
• Design Híbrido para Canvas
• Sincronização Offline e UX de Conflito
• Snapshots, Logs de Operações e Compactação
• Histórico de Versões, Undo e Comentários
• Presença, Cursores e Awareness
• Permissões e Controle de Acesso
• Assets e Dados Binários Grandes
• Cache, Sharding e Estratégia Multi-Região
• Confiabilidade e Recuperação de Desastre
• Segurança e Privacidade
• Observabilidade e SLOs
• Dicas para Entrevistas
• Anti-Patterns para Evitar
• Conclusão
• Referências
• Referência Rápida

Análise de Requisitos

Um editor colaborativo não é apenas "sincronização de texto em tempo real". Ele é uma plataforma de documentos. Ele armazena intenção do usuário, estado mesclado, comentários, regras de acesso, metadados, mídia, presença e histórico recuperável.

Requisitos Funcionais

1. Usuários podem criar, abrir, editar, renomear, compartilhar e excluir documentos.
2. Múltiplos usuários podem editar o mesmo documento ao mesmo tempo.
3. Edições locais aparecem imediatamente para quem editou.
4. Edições remotas aparecem com baixa latência para colaboradores ativos.
5. O sistema preserva convergência depois de edições concorrentes.
6. O sistema suporta texto, rich text, blocos estruturados e objetos de canvas.
7. Usuários podem trabalhar offline e sincronizar depois.
8. Usuários podem ver presença, cursores, seleções e regiões ativas de colaboradores.
9. Usuários podem adicionar comentários, respostas, menções e threads resolvidas.
10. Usuários podem ver e restaurar histórico de versões.
11. Proprietários podem gerenciar permissões e revogar acesso.
12. O sistema lida com assets como imagens, fontes, exports e anexos.
13. Clientes podem reconectar sem perder edições já confirmadas.
14. Clientes podem repetir operações com segurança.
15. O sistema expõe audit logs para documentos sensíveis.

Requisitos Não Funcionais

Superfícies de Produto

Este design suporta três superfícies.

Perguntas de Clarificação em Entrevistas

Pergunte antes de desenhar arquitetura:

1. Estamos desenhando texto, rich text, canvas ou uma mistura?
2. Quantos colaboradores simultâneos por documento são esperados?
3. Offline é obrigatório ou só recuperação de reconexão?
4. O servidor deve ser autoritativo?
5. Clientes precisam de sync peer-to-peer?
6. Histórico de versões precisa ser completo ou restore por snapshots?
7. Comentários entram no mesmo modelo de merge?
8. Permissões podem mudar enquanto usuários editam?
9. Assets são editados colaborativamente ou apenas referenciados?
10. Qual latência importa mais: feedback local, visibilidade remota ou ack durável? Neste design assumimos:

• clientes web e mobile no estilo Google Docs/Figma,
• sessões em tempo real com servidor autoritativo para colaboração ativa,
• log de operações append-only e durável,
• snapshots periódicos,
• filas offline no cliente,
• suporte compatível com CRDT para modos local-first,
• planos de controle separados para comentários, assets e permissões.

Estimativas de Capacidade

Essas estimativas guiam a arquitetura. São premissas declaradas.

Escala Assumida

Usuários registrados: 300 milhões
Usuários ativos diários: 40 milhões
Documentos abertos por dia: 180 milhões
Sessões ativas de edição por dia: 60 milhões
Editores conectados simultâneos no pico: 8 milhões
Documentos ativos simultâneos no pico: 1,2 milhão
Colaboradores médios por documento ativo: 3
Colaboradores em documento quente: 200
Colaboradores em documento extremo: 1.000
Operações médias por editor ativo: 1,5 ops/s
Rajada de digitação por editor ativo: 8 ops/s
Rajada bruta de drag em canvas: 30 deltas/s antes de coalescing
Payload médio de operação armazenada: 250 bytes comprimidos

Estimativa de Conexões

Conexões WebSocket ativas no pico ~= 8.000.000
Se um processo de gateway lida com 50.000 conexões:
Processos de gateway ~= 160
Com 2x de folga:
Processos de gateway ~= 320

O plano de conexão precisa escalar horizontalmente. Ele não deve armazenar estado autoritativo de documento na memória do gateway. Gateways encerram conexões, autenticam sessões, aplicam quotas básicas e encaminham operações ao dono da sessão do documento.

Throughput de Operações

Ops/s médias dos editores ativos = 8.000.000 * 1,5 = 12.000.000 ops/s
Ops/s em rajada de digitação com 20% em burst:
8.000.000 * 20% * 8 = 12.800.000 ops/s
Deltas brutos de canvas antes de coalescing:
8.000.000 * 5% * 30 = 12.000.000 deltas/s

Isso só parece gerenciável se clientes coalescem operações ruidosas. Um editor de canvas não deve mandar cada movimento do ponteiro como mutação durável. Ele deve mandar presença efêmera para movimento de ponteiro e mudanças duráveis de propriedade em intervalos controlados.

Estimativa de Fanout

Se cada operação aceita é transmitida para todos os outros colaboradores:

Mensagens de fanout/s ~= ops_aceitas/s * (colaboradores_médios - 1)
12M * (3 - 1) = 24M mensagens realtime/s

Documentos quentes dominam o risco de cauda. Para um documento de all-hands com 1.000 pessoas:

10 digitadores ativos * 5 ops/s * 999 receptores = 49.950 mensagens/s para um documento

Um único documento popular pode pressionar um session worker. Por isso precisamos de backpressure por documento, batching de operações e divisão de fanout para documentos quentes.

Estimativa de Armazenamento

Assuma:

Operações duráveis aceitas por dia: 600 bilhões
Payload comprimido por operação: 250 bytes
Fator de replicação: 3

Dados lógicos:

600B * 250B ~= 150TB/dia

Com replicação:

150TB/dia * 3 ~= 450TB/dia físicos antes de compactação e tiering

O sistema precisa de:

• log hot append-only,
• snapshots,
• compactação,
• object storage frio,
• tiers de retenção,
• políticas de histórico por documento.

Estimativa de Snapshot

Assuma:

Snapshot médio de documento materializado: 120KB
Snapshot de arquivo grande de design: 20MB
Snapshot a cada 500 operações ou a cada 5 minutos enquanto ativo

Documentos de texto são baratos para snapshot. Arquivos de design com referências de assets e grandes grafos de objetos não são. Snapshots devem conter estado estruturado do documento, não blobs binários. Assets pertencem a um asset store e CDN.

Insight Central

As partes difíceis não são apenas algoritmos de merge. As partes difíceis são:

1. escolher o modelo de merge certo para a superfície de edição,
2. manter edição ativa rápida enquanto operações aceitas ficam duráveis,
3. lidar com reconexão e filas offline sem duplicar edições,
4. impedir que documentos quentes virem gargalos de nó único,
5. separar mutações duráveis de presença efêmera,
6. tornar permissões aplicáveis em tempo real,
7. dar ao usuário uma UX de conflito compreensível.

Arquitetura de Alto Nível

Um editor colaborativo robusto separa edição em tempo real de metadados, assets, notificações, busca e analytics. O caminho de edição deve ser pequeno, explícito e muito observado.

Componentes Principais

Princípios de Arquitetura

1. Mutações duráveis e awareness efêmero precisam ser separados.
2. Gateways devem ser substituíveis sem perda de documento.
3. Um worker pode cachear estado quente, mas não pode ser a única fonte durável.
4. IDs de operação precisam tornar retries seguros.
5. Snapshots otimizam tempo de carga, mas o log continua sendo a fonte auditável.
6. Mudanças de permissão precisam ser aplicadas no join e na mutação.
7. Semântica de merge deve seguir o modelo do documento.

Design de APIs

Editores colaborativos usam duas classes de API:

• APIs de controle para documentos, compartilhamento, comentários e assets,
• APIs realtime para sessões de edição. HTTP funciona bem para controle. WebSocket ou gRPC bidirecional funcionam bem para edição ativa. O RFC 6455 define WebSocket como canal bidirecional amigável a browsers sobre uma única conexão. gRPC bidirecional dá contratos tipados e bom suporte a backpressure em comunicação serviço-a-serviço.

Mensagem de Join Realtime

{
  "type": "join",
  "documentId": "doc_01HT8Z7ZK7K8K9",
  "sessionToken": "short_lived_join_token",
  "clientId": "c_8f4a",
  "deviceId": "d_web_991",
  "lastSeenRevision": 48219,
  "supportedProtocols": ["ot-text-v3", "canvas-props-v2", "awareness-v1"]
}

Mensagem de Envio de Operação

{
  "type": "op.submit",
  "documentId": "doc_01HT8Z7ZK7K8K9",
  "clientId": "c_8f4a",
  "clientSeq": 1042,
  "baseRevision": 48219,
  "opId": "c_8f4a:1042",
  "surface": "rich_text",
  "operation": {
    "kind": "text_insert",
    "path": ["body", "blocks", "b_77", "text"],
    "offset": 18,
    "text": " resiliente"
  }
}

Mensagem de Ack

{
  "type": "op.ack",
  "opId": "c_8f4a:1042",
  "accepted": true,
  "assignedRevision": 48220,
  "serverTime": "2026-02-12T10:00:01.221Z",
  "transformedOperation": {
    "kind": "text_insert",
    "path": ["body", "blocks", "b_77", "text"],
    "offset": 21,
    "text": " resiliente"
  }
}

O servidor pode transformar a operação antes do ack. Em OT, isso é normal. Em merge de propriedades de canvas com servidor autoritativo, o servidor pode rejeitar ou substituir uma atualização. Em CRDT, o servidor pode não transformar o payload, mas ainda atribuir metadados duráveis de sequência para armazenamento e fanout.

Mensagem de Presença

{
  "type": "presence.update",
  "documentId": "doc_01HT8Z7ZK7K8K9",
  "clientId": "c_8f4a",
  "cursor": {
    "surface": "rich_text",
    "anchor": {"blockId": "b_77", "offset": 21},
    "focus": {"blockId": "b_77", "offset": 31}
  },
  "ttlMs": 15000
}

Presença não é operação durável de documento. Ela deve expirar automaticamente. Ela deve ter rate limit agressivo.

Modelagem de Dados

O modelo separa metadados canônicos, estado colaborativo mutável, presença efêmera e histórico imutável de operações.

Entidades Centrais

Diagrama ER

Modelos de Edição: Texto, Rich Text e Canvas

A estratégia de merge começa pelo modelo do documento.

Texto Puro

Texto puro é uma sequência ordenada. Operações geralmente são:

• inserir texto em uma posição,
• deletar range,
• reter range,
• substituir range. Texto puro expõe o problema clássico de edição concorrente:

Base: "ABCD"
Usuário 1 insere "X" depois de A -> "AXBCD"
Usuário 2 deleta C no offset base 2 -> "ABD"

Se o cliente do Usuário 1 aplicar a deleção do Usuário 2 com offset obsoleto, ele pode deletar o caractere errado. O sistema precisa transformar posições ou usar identificadores de posição que sobrevivem a inserts e deletes concorrentes.

Rich Text

Rich text não é apenas caracteres. Ele inclui:

• parágrafos,
• headings,
• listas,
• tabelas,
• marcas inline,
• links,
• comentários,
• embeds,
• restrições de schema. Operações de rich text precisam preservar estrutura válida. Deletar entre células de tabela, dividir itens de lista e aplicar negrito sobre edições concorrentes pode quebrar schemas se tudo for tratado como string crua. Um design sério modela rich text como árvore ou sequência de blocos com folhas de texto.

Canvas e Editores de Design

Editores de canvas são diferentes. As unidades primárias são objetos e propriedades:

• frames,
• formas,
• camadas de texto,
• componentes,
• constraints,
• estilos,
• variantes,
• comentários,
• image fills,
• parent links,
• chaves de ordenação. O artigo público da Figma sobre multiplayer descreve um modelo próximo de um mapa de IDs de objeto para mapas de propriedades, com ordenação pelo servidor e conflitos em nível de propriedade. Esse tipo de design funciona porque muitas edições de canvas tocam propriedades independentes. Duas pessoas podem editar cor e posição do mesmo retângulo ao mesmo tempo. Essas atualizações não precisam de transformação caractere-a-caractere.

Matriz de Decisão

Sessões de Documento e Fanout em Tempo Real

Edição ativa é organizada em sessões de documento. Uma sessão de documento é o contexto vivo de coordenação para um documento aberto. Ela controla:

• head revision atual,
• buffer recente de operações,
• colaboradores conectados,
• acks pendentes,
• subscriptions de presença,
• cache quente de snapshot,
• instância do motor de merge,
• política de backpressure.

Ciclo de Vida da Sessão

Ownership de Sessão

O modelo mais simples atribui um documento ativo a um session worker. Esse worker serializa operações aceitas daquele documento. O modelo é fácil de raciocinar. Ele também combina com muitos editores colaborativos porque um documento normalmente tem poucos colaboradores ativos. Mas documentos quentes exigem cuidado. O worker pode virar gargalo se precisar:

• transformar operações,
• persistir operações,
• transmitir fanout,
• lidar com presença,
• servir deltas de catch-up,
• aplicar mudanças de permissão,
• construir snapshots.

Caminho de Fanout

Fanout de Documento Quente

Para documentos normais, o worker pode transmitir direto via gateways. Para documentos quentes, divida o fanout:

1. O worker serializa operações.
2. Ele publica operações aceitas em um tópico do documento.
3. Workers de subscription locais aos gateways fazem fanout para clientes conectados.
4. Clientes lentos recebem batches ou são forçados a resync. Isso mantém ordenação de merge centralizada sem forçar um processo a escrever em todos os sockets.

Regras de Backpressure

Protocolo de Operações e Idempotência

Editores colaborativos vivem de retries. Clientes mobile reconectam. Browsers suspendem abas. Gateways reiniciam. Usuários digitam durante perda de pacote. O protocolo de operações precisa assumir entrega duplicada e chegada fora de ordem.

Pipeline de Operação

Campos Obrigatórios

Tabela de Idempotência

O worker mantém cache recente de dedupe com limite. O log durável também força unicidade.

CREATE TABLE document_operation_dedupe (
    document_id TEXT NOT NULL,
    op_id TEXT NOT NULL,
    revision BIGINT NOT NULL,
    client_id TEXT NOT NULL,
    client_seq BIGINT NOT NULL,
    committed_at TIMESTAMPTZ NOT NULL,
    PRIMARY KEY (document_id, op_id)
);

Se o cliente repetir uma operação já aceita, o servidor retorna o ack original. Ele não deve gravar uma segunda operação.

Tratamento de Gaps

Se um cliente envia clientSeq=1044 depois de 1042, o servidor tem escolhas. Para OT:

• rejeitar e pedir resync,
• esperar brevemente a 1043,
• aceitar se operações forem independentes e base revisions válidas. Para CRDT:
• sequência ausente pode ser aceitável se dependências causais estiverem presentes,
• mas o protocolo de sync ainda precisa de state vectors para saber o que falta. Para sanidade de produto, edição ativa deve preferir regras simples:

1. manter sequência por cliente monotônica,
2. deduplicar por opId,
3. pedir resync quando gaps passam de uma janela pequena.

Validação do Envelope

O gateway pode validar:

• tamanho da mensagem,
• forma do token,
• formato do document ID,
• versão de protocolo,
• rate limit grosseiro. O worker do documento deve validar:
• permissão atual,
• schema do documento,
• base revision,
• semântica da operação,
• existência do objeto,
• validade do path,
• idempotência,
• compatibilidade de merge. Não trate o gateway como autoridade final.

OT vs CRDT: Escolhendo o Modelo de Merge

Operational Transformation e CRDTs resolvem problemas sobrepostos com trade-offs diferentes. Ambos tentam deixar múltiplas réplicas editarem estado compartilhado de forma concorrente e convergirem. A sensação operacional é diferente.

Operational Transformation

OT aceita operações geradas contra um estado antigo e as transforma contra operações concorrentes. Exemplo:

Base:       ABCD
Usuário A: insert X em 1
Usuário B: delete char em 2
Ordem do servidor: A depois B
Transforma B contra A:
delete char em 3
Resultado: AXBD

OT é atraente quando:

• o servidor é autoritativo,
• operações são compactas,
• ranges de texto dominam,
• baixo overhead de metadados no cliente importa,
• o produto já tem permissões e auditoria centralizadas. OT é difícil porque:
• funções de transformação precisam estar corretas para cada par de operações,
• rich text cria muitos edge cases,
• clientes precisam de buffers de operações pendentes,
• undo e redo ficam sutis,
• prova formal de correção é difícil.

CRDT

Um CRDT dá a cada réplica estruturas de dados capazes de aceitar mudanças locais e mesclar automaticamente. A documentação do Yjs descreve shared types manipuláveis de forma concorrente e mescláveis sem conflitos manuais. Automerge enfatiza estado local-first, edição offline, merge automático e histórico de mudanças. CRDTs são atraentes quando:

• offline-first é promessa central do produto,
• clientes podem sincronizar por caminhos de rede diferentes,
• sync peer-to-peer ou multi-device local importa,
• o app quer semântica de branch/merge,
• o servidor deve ser relay, não transformer. CRDTs são difíceis porque:
• metadados podem crescer,
• o design de schema precisa se encaixar na semântica CRDT,
• resolução de conflito pode surpreender usuários,
• rich text interleaving ainda exige algoritmos cuidadosos,
• autorização server-side fica mais complexa quando updates são opacos.

Tabela Comparativa

Causalidade e Version Vectors

O sistema precisa saber o que cada participante já viu. Em OT com servidor autoritativo, uma revision escalar do documento costuma bastar para sessões ativas:

document revision: 48220
client base revision: 48219

Em CRDT, réplicas podem precisar de state vectors ou version vectors:

{
  "clientA": 1042,
  "clientB": 318,
  "clientC": 77
}

Um version vector ajuda a responder:

• quais mudanças esta réplica já tem?
• quais mudanças faltam?
• duas mudanças são concorrentes?
• este update pode ser aplicado agora?
• precisamos de catch-up sync?

Fluxo de Decisão do Modelo de Merge

Recomendação Prática

Para um editor tipo Google Docs:

• use OT com servidor autoritativo ou CRDT de sequência maduro,
• modele o schema de rich text explicitamente,
• mantenha comentários e permissões fora do caminho baixo nível de merge de texto. Para um editor tipo Figma:
• use IDs de objeto e mapas de propriedades,
• mescle propriedades independentes de forma independente,
• use ordenação do servidor para escritas conflitantes na mesma propriedade,
• valide operações de árvore no servidor,
• use ideias de CRDT sem exigir CRDT descentralizado puro. Para um produto local-first:
• use uma biblioteca CRDT madura como Yjs ou Automerge,
• desenhe schemas em torno de shared types,
• trate armazenamento no servidor como infraestrutura de sync e backup,
• ainda construa autorização, compactação e observabilidade ao redor.

Design OT com Servidor Autoritativo

Em OT com servidor autoritativo, o servidor atribui a ordem canônica das operações. Clientes aplicam operações locais de forma otimista. O servidor transforma operações que chegam com base revisions antigas. O servidor devolve revisions aceitas para todos os clientes.

Fluxo de Rebase OT

Buffer Pendente no Cliente

Cada cliente rastreia:

• revision confirmada,
• operações locais pendentes,
• operações remotas recebidas depois de edições locais,
• projeção local do documento. Quando uma operação remota chega:

1. Transformar a operação remota contra operações locais pendentes.
2. Aplicar a operação remota transformada na projeção local.
3. Rebasear operações locais pendentes se necessário.
4. Preservar cursor do usuário com mapeamento de posição relativa.

Forma de Operação de Texto

{
  "kind": "rich_text_delta",
  "baseRevision": 100,
  "ops": [
    {"retain": 18},
    {"insert": "resiliente ", "attributes": {"bold": true}},
    {"retain": 42},
    {"delete": 3}
  ]
}

Operações em estilo delta são compactas para rich text. Mas cada tipo de operação precisa definir regras de transformação. Insert-vs-insert é gerenciável. Delete-vs-format cruzando blocos é mais difícil. Tabelas, listas aninhadas, embeds e comentários tornam isso ainda mais difícil.

Ordenação no Servidor

O worker do documento processa operações serialmente por documento. Isso não significa que o sistema inteiro é single-threaded. Significa que cada documento tem uma ordem canônica de operações. Documentos diferentes rodam em workers diferentes. Documentos quentes podem dividir fanout preservando uma autoridade de merge.

Quando Escolher OT na Entrevista

Escolha OT quando o entrevistador pedir:

• edição de texto tipo Google Docs,
• documentos controlados pelo servidor,
• permissões empresariais,
• histórico completo de versões,
• baixo overhead de metadados,
• validação central forte. Depois diga o risco: "O motor de merge é o risco. Eu manteria a primeira versão estreita: parágrafos, marcas, listas, comentários fora do log de texto e testes explícitos de transformação para cada par de operações." Isso demonstra julgamento sênior.

Design com CRDT Puro

Em um modelo CRDT puro, cada réplica pode aceitar updates locais de forma independente. Réplicas trocam updates. Se todos os updates eventualmente chegam a todas as réplicas, elas convergem.

Topologia de Sync CRDT

State Vectors

Um sync server CRDT não deve mandar o documento inteiro a cada reconexão. Ele deve comparar state vectors.

State vector do cliente:
clientA: 1042
clientB: 318
clientC: 0

Servidor tem:
clientA: 1042
clientB: 390
clientC: 77

Servidor envia:
updates clientB 319..390
updates clientC 1..77

Forças do CRDT

1. Offline-first é natural.
2. Edições locais não precisam de round trip ao servidor.
3. Réplicas podem sincronizar por caminhos flexíveis.
4. O comportamento de merge está embutido nos tipos.
5. Histórico de mudanças e branching podem virar recursos de produto.

Fraquezas do CRDT

1. Overhead de metadados precisa ser controlado.
2. Validação de updates pode ser difícil se updates binários escondem semântica.
3. Deleção e compactação exigem cuidado com tombstones.
4. Rich text interleaving ainda pode gerar resultados ruins com algoritmo ingênuo.
5. Migrações de schema são mais difíceis quando clientes offline antigos retornam depois.

Compromisso CRDT de Produção

Muitos produtos SaaS usam ideias de CRDT sem descentralizar tudo. O servidor ainda pode:

• autenticar usuários,
• autorizar acesso ao documento,
• armazenar updates duravelmente,
• compactar updates,
• fornecer snapshots,
• retransmitir awareness,
• aplicar política de workspace,
• rejeitar updates que violam restrições de produto. O merge pode continuar baseado em CRDT. Isso entrega UX local-first sem abandonar controle operacional.

Design Híbrido para Canvas

Para um editor de design no estilo Figma, OT textual puro é o modelo mental errado. O estado central é um grafo de objetos. Edições concorrentes geralmente tocam propriedades diferentes. Um design híbrido pode usar:

• ordenação de operações pelo servidor,
• registers por propriedade inspirados em CRDT,
• IDs de objeto estáveis gerados pelo cliente,
• validação de invariantes de árvore no servidor,
• fractional ordering para ordem entre siblings,
• UX explícita para conflitos destrutivos.

Pipeline de Merge em Canvas

Regras de Conflito por Propriedade

Validade da Árvore

Operações de árvore em canvas precisam impedir:

• ciclos,
• múltiplos pais,
• objetos visíveis órfãos,
• nesting inválido de componentes,
• edição de layer bloqueada,
• parent references entre páginas,
• ressurreição de objeto obsoleto. Validação de árvore pertence ao servidor. Clientes podem prever de forma otimista. O servidor decide.

Order Keys

Mudanças de ordem de layers precisam inserir entre itens. Posições inteiras densas causam reescritas em massa. Fractional indexing ou chaves lexicográficas reduzem reescritas. Exemplo:

Chave de ordem A: a0
Chave de ordem B: a2
Inserir entre: a1
Inserir de novo entre a0 e a1: a0V

Order keys eventualmente precisam de rebalanceamento. Rebalanceamento deve ser operação de manutenção gerada pelo servidor, não efeito colateral do cliente.

Sincronização Offline e UX de Conflito

Offline tem dois significados. A versão fraca é recuperação de reconexão. A versão forte é edição completa offline. Este design suporta offline forte com ressalvas explícitas.

Sequência Offline

Estado Offline no Cliente

Clientes devem armazenar:

• última revision durável do servidor,
• operações locais pendentes,
• snapshot local,
• identidade do usuário e device ID,
• versão de schema,
• versão de protocolo,
• state vector se for CRDT,
• referências de upload para assets,
• marcadores de conflito. Clientes browser podem usar IndexedDB. Clientes mobile e desktop podem usar SQLite local ou storage da plataforma.

Algoritmo de Reconexão para OT

1. Baixar operações do servidor desde lastSeenRevision.
2. Aplicar operações do servidor ao snapshot base local.
3. Rebasear operações locais pendentes sobre operações baixadas.
4. Remover operações locais que o servidor já aceitou.
5. Enviar operações rebaseadas em ordem de sequência do cliente.
6. Se a transformação falhar, marcar conflito e pedir resolução do usuário.

Algoritmo de Reconexão para CRDT

1. Enviar state vector local ao sync server.
2. Receber updates remotos faltantes.
3. Enviar updates locais faltantes.
4. Aplicar updates em qualquer ordem válida para o CRDT.
5. Persistir estado compactado.
6. Atualizar awareness separadamente.

UX de Conflito

Usuários não devem ver teoria de merge crua. Eles precisam de explicações de produto.

Snapshots, Logs de Operações e Compactação

O log de operações é a fonte de mutações aceitas. Snapshots são estruturas de aceleração. Compactação mantém documentos longos utilizáveis.

Fluxo de Persistência

Requisitos do Write-Ahead Log

O append log durável precisa de:

• ordenação por documento,
• unicidade por operation ID,
• leitura rápida depois de uma snapshot revision,
• tiers de retenção,
• checksums,
• replicação,
• ferramentas de replay,
• capacidade de backfill. Logs estilo Kafka funcionam bem para streaming. Uma tabela de banco pode funcionar em escala menor. Um log customizado pode ser justificado em cargas extremas. O ponto importante é append-only para operações aceitas.

Política de Snapshot

Crie snapshots com base em:

• contagem de operações,
• tempo de edição ativa,
• tamanho do documento,
• latência de abertura,
• pressão de compactação,
• fronteiras de histórico de versões. Exemplo:

Documento pequeno de texto: a cada 1.000 operações ou 10 minutos
Documento rich grande: a cada 500 operações ou 5 minutos
Documento canvas: a cada 200 operações ou 2 minutos durante sessão ativa
Documento idle: snapshot uma vez depois que a sessão fecha

Política de Compactação

Compactação pode:

• colapsar operações antigas em snapshots,
• remover tombstones obsoletos,
• comprimir metadados CRDT,
• coalescer atualizações ruidosas de propriedade,
• preservar checkpoints nomeados,
• preservar retenção legal/auditoria quando exigida. Compactação nunca deve remover histórico prometido ao usuário. Se o histórico diz "restaurar qualquer ponto dos últimos 30 dias", a compactação precisa preservar dados suficientes para isso.

Recuperação por Log e Snapshot

1. Carregar snapshot mais recente na revision S.
2. Ler log de operações de S + 1 até head revision H.
3. Aplicar operações deterministicamente.
4. Verificar hash calculado se existir.
5. Iniciar sessão do documento em H.

Se replay falhar, o sistema deve isolar a sessão do documento e alertar. Servir estado corrompido é pior que indisponibilidade temporária de um documento.

Histórico de Versões, Undo e Comentários

Usuários pensam em mudanças visíveis, não em operações baixo nível. O sistema pode armazenar cada operação, mas o histórico de versões deve agrupar operações em momentos significativos.

Pipeline de Histórico

Regras de Agrupamento

Agrupe operações por:

• autor,
• janela de tempo,
• seção do documento,
• tipo de operação,
• save point explícito,
• versão nomeada,
• evento de import,
• evento de restore. Exemplo:

48220..48291: Alice editou seção "Launch plan" por 3 minutos
48292..48310: Bruno moveu três frames na Página 2
48311: Carol restaurou versão "Client review"

Modelos de Undo

Undo em editores colaborativos é sutil. Operações inversas ingênuas podem sobrescrever trabalho posterior de outras pessoas. Modelos melhores:

1. Undo local reverte apenas a última ação lógica do próprio usuário.
2. Undo é transformado ou mesclado sobre operações posteriores.
3. Histórico de redo muda quando undo acontece.
4. Undo destrutivo pode exigir confirmação explícita.
5. Restaurar versão cria nova operação em vez de apagar histórico.

Restaurar Versão

Restaurar versão antiga deve gravar uma nova operação:

{
  "kind": "restore_snapshot",
  "sourceRevision": 42100,
  "restoreRevision": 48900,
  "mode": "replace_document_state"
}

Não reescreva o log de operações. Auditabilidade importa.

Comentários e Âncoras

Comentários precisam de âncoras estáveis. Para texto, âncoras podem usar posições relativas ou block IDs mais offsets que se movem com edições. Para canvas, âncoras podem usar object IDs e geometria opcional.

{
  "threadId": "th_123",
  "documentId": "doc_01HT",
  "anchor": {
    "surface": "canvas",
    "objectId": "obj_button_9",
    "x": 0.72,
    "y": 0.18,
    "revision": 88012
  },
  "status": "open"
}

Se o alvo da âncora for deletado:

• mantenha a thread no histórico,
• mostre como destacada ou resolvida por deleção,
• não mova silenciosamente para conteúdo não relacionado.

Presença, Cursores e Awareness

Presença faz colaboração parecer viva. Presença também é fácil de superdimensionar. Ela deve ser efêmera. Ela não deve poluir o log durável de operações.

Arquitetura de Presença

Tipos de Payload de Presença

Permissões e Controle de Acesso

Compartilhamento é comportamento central de produto e superfície central de segurança. Permissões precisam ser aplicadas no plano de controle e no plano realtime.

Modelo de Permissões

Fluxo de Verificação de Permissão

Versionamento de ACL

Cada documento tem um acl_version. Quando permissões mudam:

1. Incrementar acl_version.
2. Publicar evento de invalidação de ACL.
3. Sessões ativas atualizam capabilities.
4. Usuários que perderam leitura são desconectados.
5. Usuários que perderam escrita podem ficar read-only.
6. Operações pendentes não autorizadas são rejeitadas.

Checks no Momento da Mutação

Toda operação durável deve checar:

• usuário ainda tem write access,
• documento não está arquivado ou bloqueado,
• objeto não está locked,
• política do workspace permite operação,
• operação não excede quota,
• versão de schema é permitida. Checagem de permissão não acontece só ao abrir documento.

Edge Cases de Compartilhamento Externo

1. Usuário abre via link público e depois o link é desativado.
2. Usuário tem role editor e admin do workspace remove membership.
3. Usuário edita offline depois de perder acesso.
4. Usuário comenta via notificação de email depois que thread foi restrita.
5. Usuário tem leitura do documento, mas não de um asset embutido. O sistema deve falhar fechado. Edições offline enviadas após revogação não devem ser aceitas. O cliente deve explicar que o acesso mudou.

Assets e Dados Binários Grandes

Assets não pertencem ao stream realtime de edição. Um editor de design pode lidar com:

• imagens,
• vídeos,
• PDFs,
• fontes,
• thumbnails de componentes,
• exports,
• design tokens,
• previews gerados.

Regras para Assets

1. Upload primeiro, referência depois.
2. Escanear binários não confiáveis.
3. Usar signed URLs com expiração curta.
4. Amarrar permissões de asset ao documento/workspace.
5. Não enviar assets grandes por WebSocket.
6. Gerar thumbnails de forma assíncrona.
7. Preservar hashes para dedupe e integridade.

Cache, Sharding e Estratégia Multi-Região

Edição colaborativa usa chaves de partição diferentes por plano.

Chaves de Sharding

Camadas de Cache

1. Cache local de snapshot no cliente.
2. CDN para snapshots e assets.
3. Cache de token de sessão no gateway.
4. Estado quente no document worker.
5. Cache de decisão de permissão com ACL version.
6. Buffer recente de operações.
7. Cache de threads de comentário. Caches de permissão precisam incluir versão. Permissão stale é bug de segurança.

Modelo de Região Home

Atribua uma região home para cada documento. A região home controla escritas ativas daquele documento. Usuários em outras regiões conectam a um gateway próximo, mas operações roteiam para o worker da região home. Isso evita complexidade multi-leader para OT com servidor autoritativo. Em sistemas CRDT local-first, multi-região pode ser mais flexível, mas autorização e compactação ainda exigem coordenação cuidadosa.

Confiabilidade e Recuperação de Desastre

Confiabilidade é proteger trabalho confirmado. Baixa latência é secundária frente a não perder operações aceitas.

Matriz de Falhas

Fluxo de Recuperação

Recuperação de Worker

1. Heartbeat da sessão expira no diretório.
2. Scheduler elege novo worker para o documento.
3. Novo worker carrega snapshot mais recente.
4. Novo worker reproduz operações depois do snapshot.
5. Novo worker reconstrói presença conforme clientes reconectam.
6. Clientes reenviam operações pendentes com op IDs.
7. Dedupe impede duplicação de edições aceitas.

Presença pode ser perdida. Operações confirmadas do documento não podem ser perdidas.

RPO e RTO

Metas sugeridas:

RPO para operações aceitas: 0 dentro do quorum replicado do log
RPO para edições locais sem ack: best effort via retry do cliente
RTO para queda de worker: < 30 segundos por documento ativo
RTO para failover regional: < 10 minutos
RTO para presença: < 60 segundos

Seja preciso em entrevistas: "Sem perda de operação confirmada" significa que o servidor só envia ack depois de write durável. Edições locais otimistas que nunca receberam ack são problema de recuperação do cliente.

Segurança e Privacidade

Editores colaborativos armazenam planos de empresa, contratos, designs, trechos de código e notas pessoais. Segurança não pode ser adicionada depois do algoritmo de merge.

Controles de Segurança

Fronteiras de Privacidade

Separe:

• conteúdo do documento,
• comentários,
• presença,
• analytics,
• audit logs,
• índices de busca,
• notificações. Analytics não deve receber conteúdo bruto de documento, exceto quando o produto exige explicitamente e a política permite. Presença deve ter TTL. Indexação de busca deve respeitar permissões. Exports devem ser auditados em workspaces enterprise.

Observação sobre E2EE

Criptografia ponta a ponta real é difícil em editores colaborativos. O servidor geralmente precisa:

• validar operações,
• aplicar schema,
• construir índices de busca,
• gerar previews,
• escanear assets,
• aplicar política DLP,
• fornecer histórico de versões. Você pode desenhar documentos criptografados no cliente, mas muitos recursos server-side ficam limitados ou exigem protocolos criptográficos especiais. Em entrevista, explicite esse trade-off. Não prometa validação completa no servidor e conteúdo zero-knowledge sem explicar a tensão.

Observabilidade e SLOs

Um editor colaborativo precisa de observabilidade em nível de documento, sessão, operação e experiência do usuário. Médias globais de serviço não bastam. Um documento quente pode falhar enquanto dashboards globais parecem saudáveis.

Tabela de SLOs

Métricas-Chave

Monitore:

• documentos ativos,
• colaboradores ativos por documento,
• operações por segundo,
• rejeições por motivo,
• falhas de transformação,
• falhas de rebase,
• tamanho de fila pendente no cliente,
• latência de ack,
• latência de fanout,
• tamanho do send buffer do gateway,
• idade do snapshot,
• latência de append no log,
• duração de replay,
• taxa de updates de presença,
• lag de invalidação de permissão,
• taxa de reconexão,
• prompts de conflito exibidos,
• prompts de conflito resolvidos.

Dicas para Entrevistas

Uma resposta forte começa com escopo. Não pule direto para "use WebSockets". WebSockets movem bytes. Eles não resolvem convergência.

Fluxo Forte de Entrevista

1. Clarifique a superfície: texto, rich text, canvas ou misto.
2. Defina colaboração: realtime, offline, comentários, presença.
3. Estime conexões ativas, operações, fanout e armazenamento.
4. Desenhe plano de controle versus plano colaborativo realtime.
5. Escolha modelo de merge e explique por quê.
6. Detalhe protocolo de operações, idempotência e ordenação.
7. Explique snapshots, logs, histórico e recuperação.
8. Cubra permissões e revogação.
9. Adicione confiabilidade e observabilidade.
10. Nomeie anti-patterns e trade-offs.

Script de Trade-Off

Use este raciocínio:

Para texto, eu escolheria OT com servidor autoritativo ou um CRDT de sequência maduro.
Para canvas de design, eu não forçaria toda edição por OT textual.
Eu modelaria o arquivo com IDs estáveis de objeto e mapas de propriedades, mesclaria propriedades independentes e deixaria o servidor rejeitar operações inválidas de árvore.
Offline muda a decisão: se local-first é requisito central, CRDT fica mais atraente.

Erros Comuns

1. Tratar WebSocket como design inteiro.
2. Ignorar edições offline.
3. Enviar documento inteiro a cada mudança.
4. Esquecer idempotência.
5. Misturar presença com operações duráveis.
6. Assumir que last-write-wins serve para texto.
7. Ignorar revogação de permissão em sessões ativas.
8. Esquecer histórico e restore.
9. Modelar comentários só como offsets crus.
10. Não explicar fanout de documento quente.

Anti-Patterns para Evitar

1) Enviar o Documento Inteiro a Cada Edição

Isso falha em latência, bandwidth, conflitos e histórico. Envie operações ou updates CRDT. Use snapshots para carga e compactação.

2) Usar Last-Write-Wins para Texto

Last-write-wins pode ser aceitável para propriedade escalar. Não é aceitável para texto colaborativo denso. Ele perde intenção. Use OT ou CRDTs de sequência.

3) Colocar Presença no Log Durável

Presença é efêmera. Logs duráveis devem conter mutações de documento. Movimento de cursor deve expirar.

4) Confirmar Antes do Append Durável

Se o servidor envia ack antes de gravar no log durável, uma queda pode perder trabalho confirmado. Ack só depois de append durável.

5) Ignorar Mudanças de Permissão Depois do Join

Acesso pode mudar enquanto a pessoa edita. Cheque permissões em cada mutação e inscreva sessões em mudanças de ACL.

6) Tratar Comentários como Offsets Simples

Offsets se deslocam. Use âncoras que se movem com texto ou prendem em block/object IDs estáveis.

7) Deixar Um Worker Fazer Fanout para Milhares de Sockets

Documentos quentes precisam dividir fanout. Mantenha ordenação de merge centralizada, mas distribua entrega.

8) Pular Versionamento de Schema de Operação

Clientes antigos vão reconectar. Clientes offline podem voltar semanas depois. Versione todo protocolo e defina migração.

9) Compactar Sem Semântica de Produto

Compactação pode destruir restore points, audit history ou dependências CRDT. Defina retenção antes de deletar operações antigas.

10) Esconder Resolução de Conflito

Overwrites silenciosos destroem confiança. Quando intenção não pode ser preservada automaticamente, mostre caminho claro de recuperação.

Conclusão

Design de sistema para editor colaborativo é um problema de convergência embrulhado em expectativas de produto. Usuários esperam feedback local instantâneo, updates remotos de baixa latência, resiliência offline, comentários, histórico de versões, compartilhamento seguro e nenhum trabalho perdido. A arquitetura que sustenta essas expectativas tem princípios estáveis:

• separar operações duráveis de presença efêmera,
• escolher semântica de merge pela superfície de edição,
• manter log append-only de operações,
• usar snapshots para carga e recuperação,
• tornar operation IDs idempotentes,
• aplicar permissões durante sessões ativas,
• tratar sync offline como fluxo de primeira classe,
• observar o sistema por documento e operação. Para texto e rich text, OT e CRDTs de sequência são as opções centrais. Para canvas de design, um modelo híbrido de objetos e propriedades costuma ser mais limpo. Para apps local-first, bibliotecas como Yjs e Automerge dão bases fortes, mas o sistema ao redor ainda precisa de autorização, compactação, histórico e observabilidade. Se você consegue explicar esses trade-offs com clareza, consegue conduzir uma entrevista sênior de collaborative editor system design e construir um sistema que se comporta bem sob pressão real.

Referências

• Figma Engineering - How Figma's multiplayer technology works
• Google Drive API - Push notifications for resource changes
• Collabs: A Flexible and Performant CRDT Collaboration Framework
• Automerge Documentation
• Yjs Documentation
• RFC 6455 - The WebSocket Protocol
• gRPC Core Concepts - Bidirectional Streaming
• Specification and Implementation of Replicated List: The Jupiter Protocol Revisited
• Real Differences between OT and CRDT in Building Co-Editing Systems and Real World Applications
• The Art of the Fugue: Minimizing Interleaving in Collaborative Text Editing
• Google SRE Book
• Designing Data-Intensive Applications

Referência Rápida

Componentes Centrais

Regras Críticas

1. Não confunda transporte com correção de merge.
2. Não use last-write-wins para texto denso.
3. Envie ack só depois de append durável.
4. Separe mutações de documento de presença.
5. Use operation IDs para retries idempotentes.
6. Ancore comentários em posições ou objetos estáveis.
7. Recheque permissões durante sessões ativas.
8. Faça snapshot e compactação respeitando promessas de histórico.
9. Divida fanout para documentos quentes.
10. Desenhe UX de conflito antes que usuários percam trabalho.

Resumo de Escolha de Merge

Ciclo de Vida de Operação

edição local
-> apply otimista no cliente
-> submit com opId e base revision
-> servidor valida permissão e schema
-> merge/transformação
-> append no log durável
-> ack para autor
-> fanout da operação aceita
-> snapshot/compactação assíncronos

Compressão para Entrevista de 10 Minutos

1. Escopo: texto, rich text, canvas, offline, comentários, presença.
2. Escala: conexões ativas, ops/s, fanout, armazenamento.
3. Arquitetura: gateway, diretório de sessão, document workers, merge engine, log, snapshots.
4. Merge: OT para texto centralizado, CRDT para local-first, híbrido para canvas.
5. Protocolo: opId, clientSeq, baseRevision, ack depois do append durável.
6. Offline: fila local, rebase ou state-vector sync, UX de conflito.
7. Permissões: checks no join e na mutação, invalidação de ACL.
8. Confiabilidade: replay por snapshot + log, fanout quente dividido, failover regional.
9. Observabilidade: ack latency, falhas de rebase, filas pendentes, lag de revogação.
10. Riscos: correção de transform, compactação CRDT, permissões stale, perda silenciosa.

Agora você tem um blueprint de produção para desenhar editores colaborativos com decisões práticas de arquitetura, trade-offs claros de merge e raciocínio pronto para entrevistas.