Google Docs definiu um novo piso de expectativa em 2006: edição simultânea sem conflito, cursor do colega deslizando na sua tela. Implementar colaboração em tempo real exige escolher entre OT e CRDT, separar presença de persistência e dimensionar o transporte. A arquitetura abaixo cobre as decisões por trás de qualquer editor colaborativo sério.

Por que a abordagem ingênua falha?

Last-write-wins descarta teclas quando duas pessoas editam o mesmo parágrafo; a última escrita sobrescreve caracteres inteiros sem aviso. Lock de documento com uma pessoa por vez remete a interface de 1998 e mata a proposta do editor compartilhado.

OT ou CRDT: qual modelo escolher?

Operational Transformation transforma operações concorrentes contra a ordenação do servidor; o design é complexo e server-authoritative, com ShareDB como implementação clássica. CRDTs garantem convergência matemática sem coordenação central, e Yjs com Automerge lideram as implementações maduras. Os dois resolvem o mesmo problema com trade-offs opostos: OT concentra inteligência no servidor, CRDT distribui estado no cliente.

Como o Yjs funciona na prática?

O documento vira tipos compartilhados (Y.Text, Y.Map) manipulados como estruturas locais. A camada de providers abstrai a rede: y-websockets para servidor dedicado, y-webrtc para P2P. Edições offline acumulam no cliente e fazem merge no reconnect. A awareness API alimenta cursores, seleções e nomes exibidos.

Como funciona um presence indicator?

Presença é estado efêmero: posição de cursor, seleção ativa, status de digitação. Esse estado vive fora da persistência CRDT e morre com a sessão. Heartbeat a cada 15 segundos, com expiração mais rápida que o intervalo, mantém a lista de participantes honesta quando alguém fecha a aba sem avisar.

WebSockets dão conta do transporte?

Dão, e codificação binária segura a banda: updates do Yjs ficam abaixo de 100 bytes por lote de keystrokes. Salas de broadcast recebem escopo por document ID, então o relay encaminha updates apenas a quem abriu o mesmo documento.

Qual arquitetura de servidor escala?

Relay stateless atende o começo do projeto. Sem snapshotting, a memória cresce sem limite; compacte o documento a cada N updates para conter o tamanho. Redis pub/sub faz fan-out entre instâncias do relay, e sessões sticky por document ID evitam saltos de conexão no meio da edição.

Como persistir documentos colaborativos?

Snapshot com debounce de 5 segundos vai para object storage (S3, GCS) e cobre o estado atual. O log de updates fica retido para auditoria e recovery; restaurar significa replay do log sobre o último snapshot. O debounce equilibra custo de escrita com risco de perda.

Como testar edição simultânea?

Simulação determinística de mensagens atrasadas e reordenadas revela bugs de convergência que teste unitário jamais encontra. Property tests com dois clientes virtuais e seed fixa reproduzem o cenário no CI quantas vezes você precisar.