Diseñar un sistema de pizarra colaborativa en tiempo real

# Arquitectura del Pizarrón Colaborativo en Tiempo Real ## 1. Arquitectura de Alto Nivel Componentes y flujo de solicitud/datos: ``` ┌──────────────┐ Clientes Web/Móvil/Escritorio │ Clientes │ (Renderizado del lienzo, réplica CRDT local, Clientes ─────► │ (100/pizarra) │ cliente WebSocket, búfer sin conexión) └──────┬───────┘ │ HTTPS (REST) + WSS (WebSocket) ┌──────▼───────┐ │ CDN │ (recursos estáticos, imágenes exportadas) └──────┬───────┘ ┌──────▼───────────────┐ │ Balanceador de Carga Global │ (L7, terminación TLS, │ + Puerta de Enlace API │ autenticación, limitación de tasa) └───┬───────────────┬───┘ Tráfico REST │ │ Actualización WS (pegajoso por sessionId) ┌──────────────▼──┐ ┌─────▼───────────────┐ │ Servicios de │ │ Servidores de Colab │ │ Aplicación │ │ en Tiempo Real (WS)│ │ Sin Estado │ │ - mantener estado │ │ (auth, CRUD de │ │ de pizarra en │ │ pizarras, │ │ memoria │ │ compartir, │ │ - fusionar ops (CRDT)│ │ exportaciones) │ │ - transmitir deltas│ └───┬────────┬─────┘ │ │ │ │ ┌────▼────┐ ┌───▼────────┐ ┌───────▼──┐ ┌───▼─────┐ │ Redis │ │ Enrutamiento│ │ DB de │ │ Almacén │ │ Pub/Sub │ │ de Sesión │ │ Metadatos│ │ de Objetos│ │+Presencia│ │(Hash Consistente)│ │(Postgres)│ │ (S3) │ └─────────┘ └────────────┘ └──────────┘ └─────────┘ │ ┌───────▼─────────────┐ ┌─────────────────────────────┐ │ Almacén de Documentos/│ │ Trabajadores Asíncronos │ │ Operaciones │◄──│ (Cola Kafka) │ │ (DynamoDB/Cassandra: │ │ - instantáneas │ │ registro de ops + │ │ - generación de miniaturas/ │ │ instantáneas) │ │ exportaciones │ └─────────────────────┘ │ - análisis │ └─────────────────────────────┘ ``` **Resumen de la interacción:** Los clientes se autentican a través de la Puerta de Enlace de la API (REST), luego abren un WebSocket persistente a un servidor de Colaboración en Tiempo Real. La puerta de enlace utiliza hash consistente en `sessionId` para que todos los participantes de una pizarra aterricen en el mismo servidor (o un pequeño conjunto de réplicas), manteniendo el estado vivo autoritativo en un solo lugar. Los Servicios de Aplicación manejan el CRUD no en tiempo real (creación de pizarras, compartir, listar, exportar). Redis Pub/Sub actúa como puente entre los servidores en Tiempo Real para que, si los participantes se dividen entre instancias, las operaciones aún se propaguen. Los trabajadores asíncronos persisten periódicamente instantáneas y el registro de operaciones en almacenamiento duradero. ## 2. Comunicación en Tiempo Real - **Protocolo:** WebSocket (WSS) para mensajería bidireccional de baja latencia y dúplex completo. Como respaldo, utiliza HTTP long-polling a través de una biblioteca como Socket.IO para redes restrictivas. Se consideran los canales de datos WebRTC para la comunicación punto a punto de cursores/presencia, pero se elige un modelo con servidor intermediario por simplicidad y fiabilidad. - **Modelo de mensajes:** Los clientes envían **operaciones/deltas** pequeñas (por ejemplo, `{tipo:'agregar_trazo', objId, puntos, color}`, `{tipo:'mover_obj', objId, dx, dy}`) en lugar del estado completo de la pizarra. El servidor valida, asigna una secuencia/versión, fusiona y transmite el delta a todos los demás miembros de la sesión. - **Fan-out:** Cada servidor en Tiempo Real mantiene el conjunto de conexiones por pizarra en memoria y transmite los deltas directamente. Para pizarras cuyos miembros abarcan varios servidores, el servidor de origen publica la operación en un canal Redis Pub/Sub con clave `sessionId`; los servidores suscritos retransmiten a sus conexiones locales. - **Presencia y cursores:** Datos de alta frecuencia y bajo valor (posiciones de cursor en vivo, selecciones) se limitan en velocidad (aprox. 30–60 ms) y se envían con el mejor esfuerzo, nunca se persisten. - **Objetivo de latencia (<200 ms):** Se logra mediante clústeres de Tiempo Real regionales, enrutamiento pegajoso (sin saltos entre regiones), cargas útiles binarias diminutas/JSON compactas y renderizado local optimista (el cliente aplica su propia operación inmediatamente y luego reconcilia). ## 3. Modelo de Datos **Metadatos de la pizarra (Postgres — relacional, transaccional):** - `pizarras(id_pizarra, id_usuario_propietario, titulo, fecha_creacion, fecha_actualizacion, id_ultima_instantanea)` - `usuarios(id_usuario, nombre, email, ...)` - `permisos_pizarra(id_pizarra, id_usuario, rol[propietario|editor|visor])` - `sesiones(id_sesion, id_pizarra, fecha_inicio, numero_usuarios_activos)` **Contenido de la pizarra (DynamoDB/Cassandra — alto rendimiento de escritura, amigable para anexar): - **Registro de operaciones:** clave de partición `id_pizarra`, clave de ordenación `version` (monotónica). Cada fila es una operación `{tipo_op, id_objeto, carga_util, id_usuario, timestamp}`. - **Instantáneas:** blobs de estado completo materializados periódicamente `{id_pizarra, version_instantanea, estado_json/binario}` almacenados en almacenamiento de objetos (S3) con una fila de puntero. Cargar una pizarra = última instantánea + reproducción de operaciones desde esa versión de instantánea. **Estructura del objeto dentro de una pizarra:** ``` ObjetoPizarra { id, tipo: "trazo" | "texto" | "nota_adhesiva", capa/zIndex, geometria: { x, y, ancho, alto, rotacion }, props: { // específico del tipo trazo: { puntos:[...], color, grosor }, texto: { contenido, fuente, color }, nota_adhesiva: { contenido, color_fondo } }, creadoPor, modificadoPor ultimo, version } ``` **Resolución de conflictos:** Utilizar un **CRDT** (por ejemplo, un CRDT de lista/mapa como los de Yjs/Automerge) u OT para el conjunto de objetos, de modo que las ediciones concurrentes (dos usuarios moviendo/editando objetos diferentes o iguales) converjan de forma determinista sin un bloqueo central. Cada objeto lleva un reloj lógico para la última escritura gana en actualizaciones de propiedades conflictivas. **Activos grandes/binarios** (imágenes subidas, PNG/PDF exportados) residen en almacenamiento de objetos tipo S3, referenciados por URL en el objeto. ## 4. Estrategia de Escalabilidad y Fiabilidad **Escalado a 10k sesiones / 1M de usuarios:** - **Nivel de aplicación sin estado:** Escalado horizontal automático detrás del balanceador de carga; trivial añadir nodos. - **Nivel en tiempo real:** Fragmentado por `sessionId` mediante hash consistente. Con un máximo de 100 usuarios por pizarra, 10k sesiones = hasta ~1M de conexiones WS concurrentes. Un solo nodo afinado maneja ~10–50k conexiones; el fan-out se dimensiona para que los miembros de cada pizarra se concentren en un nodo. Escalado automático por recuento de conexiones y CPU. - **Redis:** Agrupado, utilizado para fan-out Pub/Sub y presencia; particionado por sesión. - **Bases de datos:** Postgres con réplicas de lectura para metadatos; DynamoDB/Cassandra escalan horizontalmente para el registro de operaciones de alto volumen. El almacenamiento de objetos escala efectivamente hasta el infinito. - **Instantáneas:** Los trabajadores asíncronos compactan el registro de operaciones en instantáneas en una cadencia (por ejemplo, cada N operaciones o T segundos) para limitar el costo de reproducción y el almacenamiento. **Alta disponibilidad (99.9%):** - Despliegue multi-AZ para cada nivel; multi-región para recuperación ante desastres. - Los servidores en tiempo real se ejecutan con una réplica/standby en caliente por pizarra; en caso de fallo de un nodo, los clientes se reconectan automáticamente y el nuevo nodo rehidrata el estado de la última instantánea + registro de operaciones (los últimos segundos de operaciones en memoria pueden ser reenviados por los clientes desde su búfer local). - Comprobaciones de estado + failover automatizado en el balanceador de carga. - Backpressure y limitación de tasa para proteger contra tormentas de operaciones. - El registro de operaciones duradero proporciona un punto de recuperación: no se pierde trabajo confirmado incluso en caso de caída del servidor. ## 5. Compromisos **Compromiso elegido: Latencia/disponibilidad sobre consistencia fuerte (AP sobre CP), usando CRDTs.** Priorizo la capacidad de respuesta inferior a 200 ms y la tolerancia a la desconexión permitiendo a los clientes aplicar ediciones de forma optimista y resolviendo conflictos con CRDTs/última escritura gana, aceptando la **consistencia eventual**. El beneficio: la interfaz de usuario se siente instantánea, los usuarios pueden editar durante breves particiones de red y el sistema permanece disponible durante los failovers. El costo: en casos raros de ediciones concurrentes, el resultado convergente puede no coincidir con la expectativa intuitiva de ningún usuario (por ejemplo, ediciones simultáneas al mismo texto), y los metadatos de CRDT añaden sobrecarga de memoria/almacenamiento. Para un pizarrón, esta es la decisión correcta: la colaboración creativa valora la fluidez y la disponibilidad mucho más que la estricta consistencia serializada que impondría un enfoque transaccional/de bloqueo (CP), lo que añadiría latencia de ida y vuelta y reduciría la disponibilidad durante las particiones. **Compromiso secundario:** mantener el estado vivo autoritativo en memoria en un solo nodo de Tiempo Real por pizarra (transmisiones rápidas, fusión simple) frente a un nivel completamente sin estado (más resistente pero mayor latencia). Mitigado con instantáneas + registro de operaciones para que cualquier nodo pueda reconstruir el estado en caso de failover.

1. Arquitectura de Alto Nivel Un buen diseño es un híbrido de APIs sin estado, workers de colaboración en tiempo real con estado, almacenamiento duradero y un flujo de eventos. Componentes principales: - Clientes web/móviles - CDN para activos estáticos - Pasarela de API / Balanceador de carga - Servicio de autenticación - Servicio de metadatos de pizarra - Servicio de colaboración en tiempo real - Enrutador de sesiones / servicio de presencia - Bus de mensajes / flujo de eventos - Tubería de persistencia - Base de datos principal para metadatos - Almacén de objetos/documentos para instantáneas de pizarra y estado de elementos - Caché (Redis) - Monitorización, trazado, limitación de velocidad Diagrama de texto: Cliente -> CDN para activos de la aplicación -> Pasarela de API / LB -> Servicio de autenticación -> Servicio de API de pizarra -> Enrutador de sesiones -> Nodos de colaboración en tiempo real (WebSocket) -> Estado de sesión en memoria / Redis -> Tema Pub/Sub o Kafka por partición -> Workers de persistencia -> Almacén de instantáneas -> Base de datos de metadatos Flujo: - El usuario abre la aplicación y se autentica. - El cliente recupera los metadatos de la pizarra y el último estado persistido a través de las APIs REST/HTTP. - El cliente luego se actualiza a WebSocket para la sesión de la pizarra. - El enrutador de sesiones envía al cliente al nodo de colaboración responsable de esa pizarra. - Los usuarios envían operaciones como segmento de trazo de dibujo, creación de cuadro de texto, mover objeto, editar nota adhesiva. - El nodo de colaboración valida, secuencia y transmite las operaciones a todos los participantes de la sesión. - Las operaciones se añaden a un registro de eventos y se compactan periódicamente en instantáneas. - Al reconectar o reabrir, el cliente carga la última instantánea más las operaciones recientes. Particionamiento práctico: - Utilice hashing consistente o un servicio de mapeo de pizarra a nodo para que una sesión de pizarra sea propiedad de un nodo de colaboración a la vez. - Esto simplifica la ordenación y el manejo de conflictos. - Con 10.000 sesiones concurrentes y hasta 100 usuarios/sesión, el sistema es grande pero manejable con escalado horizontal de nodos de colaboración. 2. Comunicación en Tiempo Real Protocolo: - WebSocket sobre TLS es la opción principal. - Razón: comunicación bidireccional de baja latencia, amplio soporte de navegador/móvil, más simple que el sondeo largo y eficiente para actualizaciones pequeñas y frecuentes. Modelo de actualización: - El cliente envía operaciones, no el estado completo de la pizarra. - Operaciones de ejemplo: - start_stroke, append_stroke_points, end_stroke - create_text, edit_text - create_sticky, move_object, resize_object, delete_object - El nodo de colaboración marca con fecha y secuencia las operaciones y las transmite a todos los clientes de esa pizarra. Ordenación y distribución: - Dentro de una sola pizarra, mantenga un número de secuencia monótonamente creciente. - Todas las operaciones de esa pizarra pasan por su nodo de colaboración propietario, que proporciona un orden total por pizarra. - Transmisión local a los clientes conectados; si hay réplicas o varios nodos sirven la misma pizarra para conmutación por error, utilice Redis Pub/Sub o Kafka para la replicación/eventos. Objetivo de latencia inferior a 200 ms: - Mantenga los nodos de colaboración geográficamente cerca de los usuarios utilizando despliegues regionales. - Utilice enrutamiento fijo para que todos los usuarios de una pizarra accedan al mismo nodo en la región cuando sea posible. - Transmita solo deltas, comprima cargas útiles, agrupe puntos de lápiz cada pocos milisegundos. - Para el dibujo a mano alzada, permita la representación optimista local inmediatamente en el remitente antes de la confirmación del servidor, y luego reconcilie si es necesario. Manejo de conflictos: - Para ediciones basadas en objetos como mover cuadro de texto o editar nota adhesiva, utilice versionado por objeto. - Para estados altamente concurrentes, utilice la transformación operacional o la fusión inspirada en CRDT si se necesita edición multiusuario enriquecida. - Para un sistema de pizarra de alto nivel, un modelo más simple es aceptable: - Los trazos de lápiz son solo de adición y se fusionan bien de forma natural. - Las transformaciones de objetos utilizan el último en escribir o la ordenación del servidor. - El contenido de texto puede utilizar inicialmente un bloqueo de edición de objeto completo más simple, o evolucionar más tarde a OT/CRDT para la edición de texto concurrente. 3. Modelo de Datos Utilice un modelo dividido: base de datos relacional de metadatos + contenido de pizarra en almacenamiento de documentos/blobs + registro de operaciones. A. Metadatos de la pizarra Tabla: Whiteboard - board_id - owner_user_id - title - created_at - updated_at - last_snapshot_id - access_policy - region - status Tabla: WhiteboardMember - board_id - user_id - role (owner/editor/viewer) - invited_at Tabla: ActiveSession - session_id - board_id - user_id - connection_id - joined_at - last_heartbeat - presence_state B. Modelo de contenido de pizarra Represente la pizarra como una colección de elementos en un lienzo infinito o delimitado. Campos base del elemento: - element_id - board_id - type: stroke | text | sticky_note | shape - created_by - created_at - updated_at - z_index - position {x, y} - rotation - style object - version - deleted flag Elemento de trazo: - element_id - points: lista de puntos comprimida por polilínea o Bezier - color - width - opacity Elemento de texto: - element_id - text_content - font_family - font_size - bounding_box Elemento de nota adhesiva: - element_id - text_content - background_color - bounding_box C. Registro de operaciones Tabla o flujo: BoardOperation - op_id - board_id - seq_no - user_id - op_type - target_element_id - payload - client_timestamp - server_timestamp Ejemplos de carga útil: - crear elemento con propiedades iniciales - añadir puntos de trazo - mover objeto de posición antigua a nueva posición - parchear texto - eliminar elemento D. Instantáneas Objeto de instantánea almacenado en almacenamiento de documentos/blobs: - snapshot_id - board_id - base_seq_no - created_at - estado de pizarra serializado o particiones espaciales fragmentadas Por qué instantáneas + registro de operaciones: - Replantear todo el historial para siempre se vuelve demasiado lento. - Las instantáneas permiten una carga rápida. - Las operaciones recientes después de la instantánea restauran el estado más reciente. Optimización opcional para pizarras grandes: - Fragmentación espacial: particionar el lienzo en mosaicos/regiones para que los clientes carguen solo el contenido visible. - Útil si las pizarras se vuelven muy grandes. 4. Estrategia de Escalabilidad y Fiabilidad Escalabilidad A. Escalado horizontal de nodos de colaboración - El servicio de colaboración es el camino crítico. - Cada nodo mantiene en memoria las sesiones de pizarra activas asignadas a él. - Las sesiones se fragmentan por board_id. - Si el tamaño promedio de la sesión es modesto, se pueden alojar muchas sesiones por nodo. - El balanceador de carga + enrutador de sesiones aseguran que los usuarios se unan al nodo correcto. B. Persistencia basada en eventos - No escriba sincrónicamente cada punto del lápiz en la base de datos principal antes de la transmisión; eso perjudicaría la latencia. - En su lugar: - el nodo de colaboración acepta la operación - la añade a un registro duradero / cola replicada - la transmite inmediatamente - los workers asíncronos la persisten y la compactan en instantáneas - Para la durabilidad, utilice Kafka/Pulsar o un registro de escritura anticipada replicado antes de la confirmación si se necesitan garantías más sólidas. C. Tráfico de dibujo eficiente - La herramienta de lápiz puede generar muchos puntos por segundo. - Reduzca el volumen mediante: - simplificación de puntos en el lado del cliente - agrupación de puntos cada 10-30 ms - codificación binaria en lugar de JSON verboso si es necesario - gzip/permessage-deflate en WebSocket D. Caché - Caché de Redis para metadatos de pizarra, presencia, mapa de enrutamiento, instantáneas activas. - Las pizarras y permisos recientes se pueden almacenar en caché para reducir la carga de la base de datos. E. Estrategia de almacenamiento - Base de datos relacional (PostgreSQL/MySQL) para usuarios, pizarras, permisos, metadatos de uso compartido. - Almacén de documentos/blobs (S3/almacenamiento de objetos o base de datos de documentos) para instantáneas. - Sistema de flujo/registro para operaciones. - Esto evita forzar a una sola base de datos a manejar todos los patrones de acceso. Fiabilidad / Alta Disponibilidad A. Despliegue Multi-AZ - Ejecute la API, los nodos de colaboración, Redis y las bases de datos en múltiples zonas de disponibilidad. - Los balanceadores de carga verifican el estado de las instancias y redirigen automáticamente. - Se puede lograr un tiempo de actividad del 99,9% con Multi-AZ y despliegues continuos. B. Conmutación por error del nodo de colaboración - Dado que la propiedad de la pizarra tiene estado, el fallo del nodo es importante. - Mitigación: - las operaciones se replican continuamente en un registro duradero - puntos de control en memoria periódicos o instantáneas rápidas - el enrutador de sesiones detecta la pérdida del nodo y reasigna la pizarra a otro nodo - los clientes se reconectan automáticamente y recargan la instantánea + operaciones finales - Una interrupción corta es aceptable; los usuarios se recuperan rápidamente. C. Presencia y latidos - Los latidos de WebSocket detectan desconexiones. - El servicio de presencia actualiza el estado del usuario activo con TTL en Redis. D. Contrapresión y protección - Limitación de velocidad por usuario y por pizarra. - Descartar o agrupar eventos de movimiento/arrastre excesivos. - Separar el tráfico del plano de control del plano de datos. - Proteger contra una sesión ruidosa que consuma todos los recursos del nodo. E. Opciones de durabilidad Dos opciones: - Menor latencia: confirmar después de que la operación se acepte en memoria y se replique asíncronamente. - Mayor durabilidad: confirmar solo después de añadir al registro replicado. Yo elegiría la confirmación después de añadir al registro para mutaciones de objetos y el tratamiento agrupado para segmentos de lápiz para equilibrar fiabilidad y velocidad. Razonamiento de capacidad - 10.000 sesiones concurrentes x un promedio de quizás 10 usuarios activos/sesión son 100.000 conexiones concurrentes en promedio; en el peor de los casos, 1.000.000 si todas las sesiones tienen 100 usuarios, pero ese probablemente no es el estado estable previsto. El diseño debería soportar cientos de miles de WebSockets horizontalmente. - Los nodos de colaboración pueden soportar cada uno decenas de miles de conexiones inactivas/ligeras o menos para sesiones pesadas, por lo que escalan con escalado automático y se fragmentan por número de pizarras activas y tasa de eventos. 5. Compromiso Compromiso principal: consistencia vs. latencia. Priorizaría la baja latencia y la colaboración fluida sobre la estricta consistencia global para cada acción. Qué significa esto: - Los clientes renderizan de forma optimista su propio dibujo inmediatamente. - El servidor proporciona ordenación autorizada por pizarra, pero algunas operaciones pueden fusionarse utilizando reglas simples como el orden del servidor o el último en escribir. - La persistencia es casi en tiempo real en lugar de bloquear cada actualización en una transacción de base de datos. Por qué este compromiso es bueno aquí: - La experiencia de usuario de la pizarra es muy interactiva; los usuarios notan el retraso mucho más que la reconciliación ocasional menor. - Los trazos de lápiz y los movimientos de objetos toleran la consistencia eventual dentro de una ventana muy pequeña. - Las transacciones serializables estrictas para todas las ediciones aumentarían la latencia y reducirían el rendimiento. Costo de esta elección: - Durante ediciones concurrentes del mismo objeto, los usuarios pueden ver pequeños saltos o actualizaciones sobrescritas. - La recuperación de un fallo de nodo puede reproducir una cola corta de operaciones. - La edición de texto concurrente enriquecida puede necesitar un mecanismo OT/CRDT más avanzado más adelante. Diseño resumido - APIs REST para autenticación, metadatos de pizarra, instantáneas. - WebSockets para colaboración en vivo. - Un nodo de colaboración propietario lógico por pizarra para secuenciación y distribución. - Redis/caché para enrutamiento y presencia. - Kafka/PubSub/registro de eventos para transmisión duradera de operaciones. - Base de datos relacional para metadatos/permisos, almacén de objetos o almacén de documentos para instantáneas y estado de pizarra. - Despliegue Multi-AZ, escalado automático, reconexión/conmutación por error y creación de instantáneas asíncrona para fiabilidad y escala. Esta arquitectura cumple el requisito de casi tiempo real, admite la persistencia, escala a muchas sesiones activas y mantiene el sistema operativamente práctico.