Entrevista de diseño de sistemas: Diseñar un editor colaborativo en tiempo real

Problema y escenarios aplicables

Diseña un editor colaborativo en tiempo real que admita párrafos, encabezados, listas, texto en negrita y anclajes de comentarios. El sistema tiene 20 millones de usuarios activos diarios y mantiene 2 millones de conexiones en el pico, con 200,000 usuarios escribiendo activamente. Un editor activo produce dos actualizaciones por segundo en promedio, y un documento concurrido puede tener 100 editores simultáneos. Los colaboradores en línea deben ver una edición remota dentro de 200 milisegundos en el p95. Un usuario puede editar fuera de línea hasta por 24 horas y fusionar los cambios tras reconectarse. Una edición confirmada por el servidor no debe perderse. Los cursores, selecciones y el estado en línea pueden perderse brevemente.

El sistema también admite permisos de lector, comentarista y editor, cambios de permisos, historial de versiones, deshacer por usuario y acceso multirregión. La entrevista no requiere demostrar un algoritmo CRDT u OT desde cero ni reproducir la arquitectura privada de ninguna empresa. El candidato debe elegir un modelo de resolución de conflictos, conectarlo a la estructura de datos del editor, el transporte, la persistencia y los límites de autorización, e indicar qué no puede garantizar el diseño.

El material actual de entrevistas en inglés y chino de 2026 presenta la edición colaborativa como un problema de diseño de sistemas que abarca OT versus CRDT, conexiones WebSocket, salas de documentos, presencia de cursores, edición fuera de línea, actualizaciones duraderas y recuperación por instantáneas. La documentación de Yjs proporciona evidencia fundamental para actualizaciones conmutativas, asociativas e idempotentes, sincronización delta por vector de estado y presencia no persistente. Esa combinación hace que el planteamiento sea representativo y técnicamente verificable.

Qué evalúa el entrevistador

Primero, ¿resuelve el candidato la convergencia concurrente en lugar de detenerse en "usar WebSockets"? WebSocket proporciona un canal bidireccional. No decide el resultado cuando dos usuarios insertan en la misma posición. Una respuesta sólida compara un modelo OT mediado por servidor con un modelo CRDT y elige uno para las restricciones planteadas.

Segundo, ¿separa la respuesta la experiencia local de la promesa de durabilidad del servidor? La escritura debe aplicarse localmente antes de un viaje de ida y vuelta de red. "Confirmado significa no perdido" requiere que el servidor replique una actualización de forma duradera a través de zonas de disponibilidad antes de devolver un ack. Hasta entonces, el cliente mantiene la actualización en una cola de pendientes y reintenta con la misma identidad de operación.

Tercero, ¿separa el diseño el contenido duradero de la presencia efímera? El contenido del documento, los anclajes de comentarios y el historial de versiones deben recuperarse. El movimiento del cursor es de alta rotación y caduca tras la desconexión. Persistir cada movimiento de cursor en el registro del documento aumenta los costos y contamina la recuperación con estado obsoleto.

Cuarto, ¿puede el candidato razonar sobre la semántica de texto enriquecido? Una secuencia de caracteres convergente no hace que un árbol de documento sea válido automáticamente. Las listas, tablas, anclajes de comentarios, actualizaciones de esquema y el alcance de deshacer necesitan modelos, versiones e invariantes explícitos. Los desplazamientos de enteros simples también se mueven tan pronto como un usuario remoto inserta antes de ellos.

Finalmente, ¿la capacidad, los puntos calientes, la propiedad multirregión, los permisos y la verificación forman un circuito cerrado? Una respuesta sólida calcula la carga de escritura y la distribución por sala, delimita a los clientes lentos, explica por qué las ediciones fuera de línea revocadas no pueden simplemente fusionarse y utiliza actualizaciones reordenadas, duplicados, particiones y conmutación por error para demostrar la convergencia y durabilidad.

Preguntas aclaratorias antes de responder

• ¿Qué se está editando? El diseño principal utiliza un árbol estructurado de texto enriquecido. Los bytes de imagen residen en almacenamiento de objetos; el documento contiene referencias y atributos.
• ¿Cuál es el significado de producto de un conflicto? Las actualizaciones concurrentes convergen de manera determinista sin sobrescribirse entre sí. El sistema no infiere la intención de negocio de dos oraciones contradictorias.
• ¿Qué significa confirmado (acknowledged)? El servidor confirma solo después de que la actualización ingresa en un registro duradero replicado a través de tres zonas de disponibilidad en la región principal.
• ¿Se requiere un orden lineal global? No. El contenido converge a través del CRDT. Existe un desplazamiento de registro para auditoría, recuperación y marcas de agua de confirmación, no para la corrección de la fusión.
• ¿Cuánto tiempo puede permanecer un cliente fuera de línea? Hasta 24 horas. Conserva el estado CRDT local y las actualizaciones no confirmadas, luego se reautoriza antes de intercambiar deltas.
• ¿Cuáles son los niveles de permisos? Un viewer lee, un commenter modifica solo el dominio de comentarios y un editor modifica el contenido. La unión, la reconexión y cada escritura están autorizadas.
• ¿Es duradero el estado del cursor? No. La presencia utiliza latidos y un TTL. Una actualización de cursor perdida se reemplaza con la siguiente actualización de estado.
• ¿Pueden varias regiones aceptar escrituras para el mismo documento? El diseño principal asigna a cada documento una región de origen y reenvía las escrituras allí, simplificando la autorización, auditoría y conmutación por error.
• ¿Cuánto tiempo se retiene el historial de versiones? Supongamos que las versiones visibles para el usuario se retienen durante 30 días. Son distintas de las instantáneas compactadas utilizadas para la sincronización en línea.
• ¿Está el cifrado de extremo a extremo dentro del alcance? El diseño principal permite que el servidor valide permisos y el esquema de contenido. El cifrado de extremo a extremo es un balance a considerar posteriormente.

Estructura de respuesta de 30 segundos

“Utilizaría un CRDT retransmitido por servidor: aplicar ediciones localmente, reautorizar cada actualización de WebSocket, confirmar solo después de la persistencia duradera entre zonas, y luego transmitir por sala de documento. Las reconexiones utilizan vectores de estado para diferencias faltantes o cargan una instantánea; el contenido duradero y la presencia basada en TTL se mantienen separados. La carga pico es de 400,000 actualizaciones o aproximadamente 120 MB/s. Una sala concurrida de 100 editores genera alrededor de 19,800 entregas remotas por segundo, por lo que las puertas de enlace agrupan actualizaciones y limitan los búferes de clientes lentos. Probaría actualizaciones reordenadas y duplicadas, reconexiones fuera de línea de 24 horas, revocación de permisos y conmutación por error de región de origen para verificar la convergencia y durabilidad”.

Análisis detallado paso a paso

Comencemos con siete invariantes:

1. La entrada local nunca espera a la red, y las réplicas que reciben todas las actualizaciones convergen en el mismo documento válido.
2. El servidor confirma una actualización de contenido solo después de que la persistencia duradera entre zonas tiene éxito.
3. Los reintentos, transmisiones duplicadas y entregas reordenadas no pueden aplicar una edición dos veces ni cambiar el resultado final.
4. La identidad y los permisos actuales provienen de la sesión del servidor, nunca de un rol dentro de la carga útil de la actualización.
5. El contenido, los comentarios y el historial de versiones se recuperan; los cursores y el estado en línea pueden caducar.
6. Un cliente incompatible con el esquema no puede continuar escribiendo estructuras desconocidas.
7. Cada descarte, rechazo, degradación y resultado de recuperación es observable.

Paso uno: elegir entre OT y CRDT.

OT comúnmente utiliza una versión ordenada del servidor como contexto y transforma cada operación entrante frente a operaciones concurrentes. Se adapta a un sistema con autoridad central en el servidor con un motor de transformación establecido, pero las funciones de transformación, el historial retenido y el rebase fuera de línea deben ser todos correctos. Un CRDT codifica la concurrencia en la estructura de datos. Las actualizaciones pueden llegar en diferentes órdenes y más de una vez, y las réplicas convergen después de recibirlas todas. Los costos son metadatos causales, marcadores de eliminación, enlaces complejos de texto enriquecido y manejo separado para autorización y conflictos semánticos.

Dado que el planteamiento requiere edición fuera de línea de 24 horas y acceso multirregión, el diseño principal elige un CRDT maduro de secuencia/árbol con un retransmisor de servidor y persistencia duradera. CRDT no requiere una implementación descentralizada y no elimina el servidor. El servidor sigue siendo propietario de la identidad, validación de esquemas, límites de tamaño, confirmación duradera, historial, cumplimiento y distribución por sala.

Paso dos: definir el documento estructurado y el contrato de mensajes.

La raíz del documento contiene bloques con ID estables. Los párrafos, encabezados y elementos de lista poseen texto CRDT y atributos de formato. Los hilos de comentarios residen en un dominio separado y se anclan a rangos con posiciones relativas. Una versión de esquema define los nodos, atributos y reglas de migración permitidos. Un desplazamiento de enteros es inestable: una inserción antes de él cambia a lo que apunta. Una posición relativa se adjunta a un elemento CRDT y se resuelve de manera consistente después de que las réplicas convergen.

El subprotocolo WebSocket puede utilizar estos mensajes de aplicación:

join {
  documentId, sessionId, schemaVersion, stateVector
}

update {
  documentId, clientId, clientSeq, schemaVersion, payload
}

ack {
  clientId, clientSeq, durableOffset
}

sync {
  payload, durableOffset, schemaVersion
}

presence {
  sessionId, relativeCursor, relativeSelection, statusSeq
}

(documentId, clientId, clientSeq) es la clave de idempotencia de reintento. durableOffset admite confirmaciones y auditoría, pero no participa en la corrección de fusión de CRDT. Los mensajes tienen límites de tamaño comprimido y descomprimido además de una lista de permisos de esquema. Los nodos desconocidos o los cambios de dominio no autorizados se rechazan explícitamente en lugar de transmitirse.

Paso tres: separar las rutas de carga, salas en vivo y almacenamiento.

Client
  -> HTTPS snapshot service -> metadata + snapshot store
  -> WebSocket gateway -> document room router -> collaboration service
                                              -> durable update log
                                              -> room pub/sub -> gateways

Client
  -> presence channel -> regional ephemeral store -> room fan-out

El cliente primero carga los metadatos del documento, el esquema actual y una instantánea compactada reciente sobre HTTPS, luego abre un WebSocket. La puerta de enlace gestiona conexiones y suscripciones a salas, pero no inventa reglas de fusión. El servicio de colaboración enruta por documento a su región de origen, autoriza y valida cada actualización, la persiste, la confirma y la publica. El bus de sala publica una vez a cada puerta de enlace con suscriptores, y cada puerta de enlace realiza la distribución localmente en lugar de enviar un mensaje entre nodos por destinatario.

Paso cuatro: hacer que la edición local, la confirmación y el reintento sean una máquina de estados explícita.

Una edición local actualiza la vista inmediatamente e ingresa en una cola de pendientes persistente a nivel local. Mientras está en línea, el cliente puede agrupar pulsaciones de teclas adyacentes en una ventana de 20 a 50 milisegundos para reducir la cantidad de mensajes. Esa temporización es una suposición de entrada y debe ajustarse con pruebas de interacción. Para cada actualización, el servidor autentica la sesión, lee el permiso actual, valida el esquema y los límites de recursos, añade al registro replicado, devuelve un ack y transmite. Solo el ack elimina la actualización de la cola de pendientes.

Si la conexión falla después de la confirmación (commit) pero antes del ack, el cliente reintenta el mismo clientSeq. Una restricción de unicidad del servidor puede devolver la confirmación original. La idempotencia de CRDT también hace que una aplicación repetida sea segura, pero los registros de auditoría y facturación aún necesitan deduplicación. Un cliente lento recibe un búfer de envío delimitado. Después de la marca de agua alta, la puerta de enlace descarta primero la presencia y luego solicita al cliente que se resincronice a partir de un vector de estado en lugar de permitir que una conexión consuma memoria ilimitada de la sala.

Paso cinco: utilizar vectores de estado para la sincronización en línea, fuera de línea y reconexión.

Las actualizaciones de CRDT conmutativas, asociativas e idempotentes permiten que las réplicas reciban actualizaciones en diferentes órdenes y reintenten de forma segura. Al reconectarse, un cliente envía un vector de estado que describe el estado causal que ya tiene, y el servidor calcula la diferencia faltante. Si el delta es demasiado grande, el esquema cambió o la ventana de historial en línea expiró, el servidor envía la instantánea completa de CRDT actual y luego aplica las actualizaciones locales aún autorizadas.

El orden es autenticar, autorizar, negociar esquema, y luego intercambiar contenido. Si el permiso de edición fue revocado mientras el usuario estaba fuera de línea, la convergencia no es permiso para aceptar los cambios. El servidor devuelve un error estable permission_revoked y mantiene una ruta de recuperación local para exportar o copiar, pero no escribe el borrador en el documento compartido. El producto sacrifica "toda edición fuera de línea se fusiona" para preservar el control de acceso actual.

Paso seis: diseñar instantáneas, historial de versiones y compactación.

El registro duradero se particiona por documentId y registra el ID de actualización, autor, esquema, carga útil, hora de recepción y desplazamiento duradero. Un compactador en segundo plano carga el estado de CRDT, combina incrementos en una instantánea cargable directamente y registra el desplazamiento cubierto. Elimina incrementos antiguos solo después de que la nueva instantánea pasa la validación, es duradera en el almacenamiento de objetos y retiene un punto de restauración para la ventana de recuperación y auditoría.

Fusionar actualizaciones binarias elimina información duplicada pero no recolecta automáticamente el contenido eliminado. Los marcadores de eliminación, la sincronización fuera de línea, los anclajes de comentarios, el deshacer por usuario y las versiones históricas interactúan entre sí. Por lo tanto, la compactación necesita pruebas con documentos reales. El historial visible para el usuario almacena instantáneas nombradas independientes o un índice de cambios; la compactación de sincronización en línea no es un sustituto del historial de versiones del producto.

Paso siete: separar la presencia y controlar la distribución de puntos calientes.

La presencia contiene una sesión, nombre para mostrar, color, cursor relativo, selección y un statusSeq monotónico, actualizado por latidos y TTL. Nunca ingresa al CRDT del documento ni al registro duradero. Los receptores descartan números de secuencia antiguos y el estado de desconexión caduca. Perder una actualización de cursor solo tiene un efecto transitorio porque la siguiente actualización la reemplaza.

Una sala de 100 editores a dos actualizaciones por segundo produce 200 actualizaciones de contenido por segundo. Enviar cada actualización a los otros 99 usuarios significa alrededor de 19,800 entregas remotas por segundo antes de la presencia. Las puertas de enlace agrupan actualizaciones de un breve intervalo de tiempo, publican por sala de documento, limitan la frecuencia de presencia y aplican marcas de agua de bytes y mensajes por conexión. Un documento extremadamente concurrido puede recibir un actor de sala dedicado y una partición de pub/sub, pero el sistema nunca muestrea ediciones de contenido duraderas para reducir la carga.

Paso ocho: recalcular la capacidad global y los recursos de conexión.

Doscientos mil editores a dos actualizaciones por segundo producen 400,000 actualizaciones por segundo. Con una carga útil binaria promedio de 300 bytes, las escrituras sin procesar son de aproximadamente 120 MB/s o 10.37 TB/día. La replicación, índices, encabezados, instantáneas e historial de versiones son adicionales. Si una conexión de puerta de enlace ocupa 50 KiB, 2 millones de conexiones necesitan alrededor de 100 GiB de estado de puerta de enlace. Con 20,000 conexiones por puerta de enlace, la línea base es de 100 puertas de enlace antes de considerar el margen para fallos y despliegues.

Estas estimaciones son puntos de partida. La salida de datos de salas concurridas, la CPU para TLS y codificación, los búferes de clientes lentos y las particiones del registro duradero pueden convertirse en cuellos de botella antes que el almacenamiento de contenido sin procesar. Monitorea la tasa de actualización y distribución por documento e inquilino, la latencia de ack, el tamaño del delta del vector de estado, las reconexiones, las marcas de agua de búfer, la antigüedad de las instantáneas y los fallos en las comprobaciones de convergencia.

Paso nueve: restringir el comportamiento multirregión, la conmutación por error y la seguridad.

Los metadatos del documento registran una región de origen y una época creciente. Un cliente ingresa a través de una puerta de enlace cercana, mientras que las escrituras de contenido se enrutan a la región de origen. La aplicación local inmediata oculta el RTT entre regiones de la escritura. Si la región de origen falla, el plano de control primero avanza la época, luego la nueva región restaura desde el registro replicado y la última instantánea. La capa de persistencia rechaza la época del actor anterior para que dos propietarios de sala no puedan emitir confirmaciones duraderas al mismo tiempo.

La convergencia de CRDT no reemplaza una decisión de autorización, una confirmación duradera o el cercado de conmutación por error (fencing). La seguridad también requiere límites para el documento, actualizaciones, tasa y ratio de descompresión; comprobaciones de Origin, sesión y autorización de documentos; cifrado en tránsito y en reposo; auditoría para compartir, cambios de permisos y exportaciones; y registros que omitan tokens de acceso, cuerpos de documentos y detalles precisos de cursores.

Paso diez: demostrar el diseño con pruebas basadas en propiedades e inyección de fallos.

Genera actualizaciones de varios clientes sobre el mismo documento inicial. Aplícalas en orden aleatorio, con duplicados, retrasos y lotes. Cada réplica debe finalizar con el mismo resultado serializado y un esquema válido. Añade inserciones en la misma posición, eliminaciones superpuestas, eliminación de un elemento padre mientras se edita su hijo, formato y texto concurrentes, anclajes de comentarios, deshacer por usuario y actualizaciones de esquemas.

Termina el servicio de colaboración después de la adición duradera pero antes del ack; el reintento debe producir una sola actualización auditada. Termínalo después del ack pero antes de la transmisión; la recuperación debe entregar la actualización. Reconéctate después de 24 horas fuera de línea y ejercita tanto las rutas de delta de vector de estado como las de instantáneas. Revoca el permiso antes de enviar actualizaciones fuera de línea; la persistencia compartida debe rechazarlas mientras conserva la recuperación local. Finalmente, realiza pruebas de carga en una sala concurrida de 100 editores con contenido y presencia, verificando la latencia p95, las marcas de agua de memoria y el orden de degradación previsto.

Ejemplo de respuesta de alta calidad

“Comenzaría con tres contratos: la entrada local se aplica de inmediato; las réplicas que reciben todas las actualizaciones convergen; y solo se confirma una actualización registrada de forma duradera a través de tres zonas de disponibilidad. El requisito de 24 horas fuera de línea favorece un CRDT estructurado y maduro, mientras que el servidor permanece autoritativo para la autenticación, el esquema, la persistencia y la distribución.

Después de cargar una instantánea CRDT, el cliente se une a una sala de documento. Una edición local se aplica primero e ingresa a una cola de pendientes bajo clientId + clientSeq, luego viaja por WebSocket como una actualización binaria. El servicio de colaboración vuelve a verificar el permiso actual, el esquema y los límites de recursos, añade de forma duradera la actualización, la confirma y la publica en la sala. Un reintento mantiene la misma secuencia. Las actualizaciones toleran el reordenamiento y la duplicación. Al reconectarse, el cliente envía un vector de estado y recibe los cambios faltantes o una instantánea completa. Si el permiso se revocó fuera de línea, la escritura compartida se rechaza y solo permanece disponible una exportación local.

El contenido y la presencia utilizan rutas separadas. Los cursores utilizan posiciones relativas, mientras que la presencia basada en TTL no se registra de forma duradera. Cada documento tiene una región de origen y una época. La conmutación por error avanza la época antes de restaurar desde el registro replicado y la instantánea, por lo que el antiguo propietario de la sala no puede continuar confirmando actualizaciones.

En el pico, 200,000 editores por dos actualizaciones por segundo equivale a 400,000 actualizaciones por segundo. A 300 bytes, eso representa 120 MB/s y 10.37 TB/día de actualizaciones sin procesar. Un documento concurrido de 100 editores genera alrededor de 200 actualizaciones y 19,800 entregas remotas por segundo, por lo que el bus de sala publica una vez, las puertas de enlace agrupan y distribuyen localmente, y los búferes de clientes lentos se encuentran delimitados. Demostraría el sistema permutando y duplicando actualizaciones hasta que cada réplica converja, luego inyectaría caídas alrededor del límite de ack, reconexiones fuera de línea de 24 horas, revocación de permisos, actualizaciones de esquema y fallo de la región de origen”.

Errores comunes

• Decir solo “usar WebSockets” → El transporte no resuelve las ediciones concurrentes → Elige OT o CRDT y explica la convergencia y el costo.
• Guardar el documento completo en cada edición → Los usuarios concurrentes se sobrescriben entre sí y el ancho de banda crece con el tamaño del documento → Envía actualizaciones incrementales fusionables.
• Confirmar (ack) tras una recepción en memoria → La caída de un proceso pierde el trabajo confirmado → Confirma después de añadir de forma duradera entre zonas.
• Tratar CRDT como autorización → La convergencia matemática no detiene a un usuario revocado → Autoriza la unión, la reconexión y cada escritura.
• Guardar cursores como desplazamientos de enteros → Las inserciones concurrentes mueven la posición deseada → Usa posiciones relativas a los elementos CRDT.
• Persistir el movimiento de cursores en el registro de contenido → El estado efímero de alta rotación infla el almacenamiento y la recuperación → Usa un canal de presencia con TTL.
• Afirmar entrega exactamente una vez (exactly-once) → Las reconexiones y transmisiones pueden duplicarse → Usa actualizaciones idempotentes, identidades únicas y estado reproducible.
• Eliminar todo el historial inmediatamente después de una instantánea → La sincronización fuera de línea, la reversión, el deshacer o la migración de esquemas pueden perder el contexto requerido → Recolecta solo más allá de las marcas de agua de recuperación validadas.
• Calcular solo el ingreso de contenido → La distribución en salas concurridas y los clientes lentos a menudo agotan los recursos primero → Calcula también la entrega, la salida de datos y los búferes.
• Aceptar escrituras activas en todas partes sin un plano de control → La propiedad de autorización, confirmación y conmutación por error se vuelve ambigua → Usa una región de origen y época.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento uno: ¿Por qué elegir CRDT en lugar de OT?

El requisito de 24 horas fuera de línea y el transporte multirregión con reordenamiento y duplicación se alinean con el modelo de actualización de CRDT, y una implementación madura puede intercambiar diferencias con vectores de estado. OT sigue siendo válido. Con un motor de transformación de servidor probado, un servicio de edición ordenado y un comportamiento fuera de línea limitado, puede proporcionar metadatos más controlados y semántica de servidor. La decisión proviene de las restricciones del producto y la capacidad del equipo, no de declarar un acrónimo universalmente más nuevo.

Pregunta de seguimiento dos: ¿Elimina CRDT la necesidad de un registro de actualizaciones duradero?

No. CRDT resuelve la fusión y la convergencia. La durabilidad confirmada, la auditoría, el historial, la recuperación y la carga en nuevos dispositivos aún necesitan un estado duradero. El sistema puede compactar incrementos en instantáneas y recolectar entradas de registro antiguas después de la ventana de recuperación, pero debe preservar un límite de durabilidad verificable y un punto de restauración.

Pregunta de seguimiento tres: ¿Qué sucede si se revocó el permiso de un usuario fuera de línea?

Vuelve a autenticar y autorizar antes de intercambiar contenido. Rechaza la escritura compartida con un error estable y conserva una copia local para exportar o copiar; no la descartes silenciosamente. Un negocio puede permitir que un administrador revise el borrador en un área de aprobación aislada, pero esa ruta no puede eludir la ACL actual del documento.

Pregunta de seguimiento cuatro: ¿Cómo funciona deshacer (undo) con varios usuarios?

Por defecto, deshace las operaciones locales más recientes del usuario actual y fusiona las operaciones inversas a través del CRDT. Restaurar una instantánea antigua completa borraría el trabajo posterior de otros usuarios. Registra el usuario y el límite de transacción para cada operación, conserva el contenido eliminado para la ventana de deshacer objetivo y define semánticas reversibles en el enlace del editor para cambios estructurales.

Pregunta de seguimiento cinco: ¿Cómo evitan los cursores saltar después de ediciones concurrentes?

Almacena los anclajes de cursor y comentarios relativos a elementos CRDT en lugar de desplazamientos de caracteres absolutos. Resuelve la posición relativa al índice actual después de aplicar actualizaciones remotas. Si tanto el anclaje como la estructura padre fueron eliminados, oculta el cursor, marca el comentario como desvinculado o recurre al bloque válido más cercano según una regla de producto explícita.

Pregunta de seguimiento seis: ¿Qué sucede si diez mil personas abren un solo documento?

Separa los editores de los lectores de solo lectura. Publica cada actualización de contenido una vez en el bus de la sala y distribuye desde las puertas de enlace. Los clientes de solo lectura pueden recibir actualizaciones fusionadas con menor frecuencia o consultar instantáneas de corta duración sin cambiar la corrección del editor. La presencia muestra solo a los participantes visibles o muestreados, y cada conexión tiene un búfer de envío delimitado. Mostrar los diez mil cursores requeriría su propio presupuesto de ancho de banda e interfaz de usuario.

Pregunta de seguimiento siete: ¿Puede el editor admitir cifrado de extremo a extremo?

Los clientes pueden cifrar las actualizaciones de CRDT mientras el servidor retransmite y almacena el texto cifrado. La desventaja es que el servidor ya no puede validar el esquema de texto enriquecido, buscar contenido, moderar, realizar exportaciones detalladas o recuperar datos perdidos fácilmente. La rotación de claves, la eliminación de miembros y las actualizaciones fuera de línea de miembros antiguos también se vuelven más difíciles. Define el modelo de amenazas y el protocolo de claves de documento, dispositivo y membresía primero; TLS alrededor de WebSocket por sí solo es cifrado de transporte, no cifrado de extremo a extremo.

Pregunta de seguimiento ocho: ¿Cómo se detecta una bifurcación silenciosa de réplicas?

Después de un período de inactividad o una reconexión, un cliente informa su vector de estado y un resumen de estado no confidencial. Compara solo réplicas en la misma marca de agua duradera; una discrepancia activa una resincronización completa y retiene una muestra de diagnóstico. Documentos de prueba continua (canary) emiten actualizaciones concurrentes conocidas desde varias regiones y verifican el resumen final, el esquema, el recuento de acks y la marca de agua del registro. Comparar resúmenes en diferentes marcas de agua en tránsito generaría falsas alarmas.