El patrón del gestor de incidencias: un modelo relacional pequeño que cabe entero

Hay una familia de aplicaciones —gestores de incidencias, clientes de correo, herramientas de planificación— cuya seña de identidad comercial es que responden antes de que sueltes la tecla. La tentación es atribuirlo a una red rápida o a un servidor cercano, y es exactamente al revés: responden así porque en el momento de pulsar no hay red de por medio en absoluto, y porque alguien decidió que el modelo de datos completo del espacio de trabajo cupiese en la memoria del navegador. Este nivel abre una serie de casos de estudio y conviene empezarla con una advertencia metodológica: de estos productos sabemos lo que sus equipos han contado en charlas y artículos, más lo que terceros han reconstruido leyendo el código que se descarga en el navegador. Distinguir esas dos fuentes no es pedantería académica, es lo que separa aprender de un caso real de repetir folclore de ingeniería.

Qué se sabe de verdad y por qué fuente

El caso mejor estudiado de esta familia es el motor de sincronización de Linear. Del propio producto hay dos fuentes primarias: una charla en React Helsinki y una segunda charla, Scaling the Linear Sync Engine, publicada en el sitio de la empresa en junio de 2023 y firmada por Tuomas Artman. Ambas son material de la casa y describen el problema en sus propios términos: un motor de sincronización en tiempo real, los apuros de escalarlo y cómo la API pública del producto acabó tomando la forma que tomó por culpa de esos apuros. Eso es lo que la empresa afirma de sí misma, y es poco más que un esqueleto.

La segunda fuente es de naturaleza distinta y hay que tratarla como tal. Existe un estudio abierto de ingeniería inversa del motor, publicado por un tercero, que describe con enorme detalle la maquinaria interna: nombres de clases minificadas, tablas de la base local, estrategias de carga. Su propia presentación afirma contar con el visto bueno del director técnico de la empresa. Lo verificable es que esa afirmación está ahí; el respaldo en sí no lo he comprobado de forma independiente. La postura razonable es usar ese material como hipótesis muy bien fundamentada sobre una implementación concreta en un momento concreto, no como especificación. El código de una aplicación web cambia sin avisar y sin número de versión.

La reserva en memoria y la hidratación diferida

Lo reconstruido describe una arquitectura de tres capas que conviene entender como una sola idea. Las entidades del dominio —incidencia, equipo, comentario, organización— se declaran como modelos con metadatos asociados a cada propiedad, y esos metadatos son los que gobiernan todo el comportamiento posterior: si la propiedad se persiste, cómo se serializa, si es una referencia a otro modelo, si se indexa. Los modelos viven en una reserva de objetos, un mapa grande indexado por identificador único, y las vistas se suscriben a ellos mediante un sistema de observabilidad reactiva. Cualquier consulta de la interfaz interroga primero a esa reserva.

Debajo hay una base local en el navegador que sirve de respaldo entre sesiones, y la pieza que hace el conjunto viable es la estrategia de carga declarada por modelo. El estudio identifica cinco: cargar en el arranque, cargar entera pero solo cuando haga falta, cargar por subconjuntos bajo demanda, cargar únicamente si alguien lo pide de forma explícita, y no salir nunca del cliente. Las entidades voluminosas —el contenido de los documentos, el historial— no están en la primera categoría. Ese reparto es la diferencia entre un arranque de un segundo y uno de treinta.

// Reconstruccion ilustrativa del patron, no del codigo real
const reserva = new Map(); // uuid -> modelo observable

function leerIncidencia(uuid) {
  const m = reserva.get(uuid);
  if (!m) return null;
  if (!m.hidratado) hidratarDesdeBaseLocal(m); // las propiedades pesadas llegan tarde
  return m;
}

La consecuencia de diseño que importa es que la latencia percibida no la produce la red sino la ausencia de red en el camino crítico de lectura. Cuando pulsas sobre una incidencia, no hay petición: hay un acceso a un mapa en memoria. Y esa arquitectura solo es posible si alguien ha aceptado antes una restricción incómoda: el modelo relacional que se sincroniza tiene que ser pequeño. No pequeño en número de filas, sino pequeño en variedad de entidades y en tamaño medio de cada una. Un gestor de incidencias cabe. Un almacén de ficheros adjuntos, no.

Transacciones, orden total y paquetes de deltas

Aquí es donde el patrón se separa con nitidez de la familia de los CRDT, y donde más conviene ser preciso. Según lo reconstruido, una escritura local se aplica de inmediato al modelo en memoria y se empaqueta como una transacción que se encola, se guarda en la base local por si la conexión cae y se envía al servidor por lotes. El servidor la ejecuta —en exclusiva, es él quien manda—, incrementa un contador global monótono y devuelve a todos los clientes conectados, incluido el que la originó, un paquete de deltas con las acciones resultantes y el número de secuencia correspondiente.

sequenceDiagram
participant UI as Interfaz
participant M as Reserva en memoria
participant Q as Cola de transacciones
participant S as Servidor
UI->>M: escribir titulo
M-->>UI: repintado inmediato
M->>Q: transaccion pendiente
Q->>S: envio por lotes
S->>S: ejecutar y aumentar el contador global
S-->>M: paquete de deltas con numero de secuencia
M->>M: aplicar y resolver la transaccion pendiente

Ese contador es la pieza conceptual central: funciona como número de versión de toda la base de datos y establece un orden total de las escrituras del sistema. Los CRDT que ocupan la mitad de este track solo necesitan un orden parcial y por eso pueden prescindir del árbitro; aquí el árbitro es imprescindible y la reconstrucción lo dice sin rodeos, señalando que el modelo se parece más a la transformación operacional que a un tipo replicado sin conflictos. La resolución de conflictos que describe es gana la última escritura, con la particularidad de que no hace falta reloj alguno, porque el orden lo fija quien recibe.

El alcance: grupos de sincronización y el techo del modelo

Queda la decisión que sostiene el edificio entero y que casi nunca aparece en las presentaciones. Si todos los clientes comparten un contador global, ¿qué impide que te lleguen los deltas de espacios de trabajo ajenos? La respuesta reconstruida son los grupos de sincronización: cada cliente declara a qué conjunto de identificadores está suscrito —su usuario, sus equipos, ciertos roles— y el servidor filtra los deltas contra esa suscripción. El control de acceso no es una capa sobre la sincronización; es el mecanismo de enrutado de la sincronización.

// El filtro de permisos y el filtro de entrega son el mismo filtro
function entregarDelta(delta, cliente) {
  const visible = delta.acciones.filter((a) =>
    cliente.gruposSuscritos.includes(a.grupo)
  );
  if (visible.length) enviar(cliente, { acciones: visible, seq: delta.seq });
}

De ahí se deduce, y esto ya es inferencia mía, el techo real del patrón: funciona mientras el subconjunto que un usuario tiene derecho a ver quepa en su dispositivo. Cuando una organización crece lo bastante, o cuando alguien tiene acceso a todo, la premisa se rompe y hay que empezar a cargar por subconjuntos, que es precisamente lo que las estrategias de carga parciales están haciendo. La arquitectura no escala indefinidamente: se degrada de forma controlada hacia el modelo cliente-servidor clásico, entidad por entidad, a medida que crece el volumen.