Google Docs definió un nuevo piso de expectativa en 2006: edición simultánea sin conflicto, el cursor del colega deslizándose en tu pantalla. Implementar colaboración en tiempo real exige elegir entre OT y CRDT, separar presencia de persistencia y dimensionar el transporte. La arquitectura siguiente cubre las decisiones detrás de cualquier editor colaborativo serio.

¿Por qué falla el enfoque ingenuo?

Last-write-wins descarta teclas cuando dos personas editan el mismo párrafo; la última escritura sobrescribe caracteres enteros sin aviso. El lock de documento con una persona por vez remite a una interfaz de 1998 y mata la propuesta del editor compartido.

OT o CRDT: ¿qué modelo elegir?

Operational Transformation transforma operaciones concurrentes contra el ordenamiento del servidor; el diseño es complejo y server-authoritative, con ShareDB como implementación clásica. Los CRDTs garantizan convergencia matemática sin coordinación central, y Yjs con Automerge lideran las implementaciones maduras. Ambos resuelven el mismo problema con trade-offs opuestos: OT concentra la inteligencia en el servidor, CRDT distribuye el estado en el cliente.

¿Cómo funciona Yjs en la práctica?

El documento se vuelve tipos compartidos (Y.Text, Y.Map) manipulados como estructuras locales. La capa de providers abstrae la red: y-websockets para servidor dedicado, y-webrtc para P2P. Las ediciones offline se acumulan en el cliente y hacen merge al reconectar. La awareness API alimenta cursores, selecciones y nombres visibles.

¿Cómo funciona un presence indicator?

La presencia es estado efímero: posición del cursor, selección activa, estado de escritura. Este estado vive fuera de la persistencia CRDT y muere con la sesión. Heartbeat cada 15 segundos, con expiración más rápida que el intervalo, mantiene honesta la lista de participantes cuando alguien cierra la pestaña sin avisar.

¿WebSockets bastan para el transporte?

Bastan, y la codificación binaria ahorra ancho de banda: los updates de Yjs quedan por debajo de 100 bytes por lote de keystrokes. Las salas de broadcast llevan scope por document ID, así que el relay reenvía updates solo a quien abrió el mismo documento.

¿Qué arquitectura de servidor escala?

Un relay stateless alcanza para el comienzo del proyecto. Sin snapshotting, la memoria crece sin límite; compacta el documento cada N updates para contener el tamaño. Redis pub/sub hace fan-out entre instancias del relay, y sesiones sticky por document ID evitan saltos de conexión en medio de la edición.

¿Cómo persistir documentos colaborativos?

Snapshot con debounce de 5 segundos va a object storage (S3, GCS) y cubre el estado actual. El log de updates queda retenido para auditoría y recovery; restaurar significa replay del log sobre el último snapshot. El debounce equilibra el costo de escrita con el riesgo de pérdida.

¿Cómo probar la edición simultánea?

Una simulación determinística de mensajes demorados y reordenados revela bugs de convergencia que el test unitario jamás encuentra. Property tests con dos clientes virtuales y seed fija reproducen el escenario en CI cuantas veces necesites.