El tercer eje, el alcance: qué parte del universo baja al cliente

Los dos ejes anteriores decidían quién manda y qué objeto viaja. El tercero decide cuánto viaja, y es el que más veces se subestima porque suena a problema de ancho de banda cuando en realidad es un problema de definición: sincronizar es siempre sincronizar un subconjunto, y elegir cómo se describe ese subconjunto determina el arranque en frío, la factura del servidor, qué consultas puede responder tu cliente sin red y, sobre todo, qué pasa el día en que alguien deja de tener permiso sobre algo que ya está grabado en su disco. Las tres granularidades que se han impuesto son sincronizarlo todo, sincronizar el resultado vivo de consultas declaradas y sincronizar colecciones definidas por reglas. Ninguna es una versión más refinada de las otras: son tres respuestas distintas a la pregunta de quién recalcula la pertenencia al conjunto y con qué frecuencia, y esa pregunta, que parece de implementación, es la que gobierna a la vez tu coste y tu capacidad de revocar.

Tres granularidades de alcance

La sincronización total hace bajar todo lo que el usuario puede ver, sin filtros posteriores. Su virtud es que elimina una categoría entera de problemas: no hay pertenencia que recalcular, no hay consulta que el cliente no pueda responder, no hay junturas rotas por ausencia y hay un único punto de reanudación para todo. Es la elección correcta con más frecuencia de lo que la gente admite, porque en herramientas internas, aplicaciones personales y espacios de equipo pequeños el conjunto entero cabe holgadamente. Sus tres límites son duros y previsibles: el tiempo del primer arranque, la cuota de almacenamiento del dispositivo y el hecho de que todo lo que baja queda expuesto a quien controle esa máquina.

La sincronización por consulta invierte el planteamiento: el cliente declara predicados —lo que ElectricSQL llama formas y Zero expresa como consultas— y el servidor mantiene vivo el conjunto de filas que los satisfacen. Lo que viaja no son solo altas y modificaciones, sino también entradas y salidas del conjunto, y esa segunda mitad es la que separa una implementación seria de un ejercicio: una fila que deja de cumplir el predicado tiene que abandonar la copia local, y el mensaje que la expulsa es tan importante como el que la trajo. La virtud es la precisión, y encaja de forma natural con una interfaz donde cada pantalla declara lo que necesita.

La sincronización por colección parte los datos en grupos nombrados según una regla, y el cliente se suscribe a un conjunto de grupos; es el modelo de reglas y cubos de PowerSync. Es más grueso que el anterior y a cambio tiene una propiedad de la que se habla poco y decide muchas arquitecturas: una colección es la misma para todos los clientes que la comparten, así que el servidor calcula su corriente de cambios una sola vez y la reparte, en lugar de mantener un conjunto vivo por cliente y por consulta. Además, cada colección lleva su propio punto de reanudación, lo que simplifica enormemente la reanudación y la reincorporación.

flowchart TD
A[quien recalcula la pertenencia] --> T[total: nadie, se fija al entrar]
A --> Q[por consulta: el servidor, por cliente y por predicado]
A --> C[por coleccion: el servidor, una vez por cubo compartido]
T --> TC[coste de arranque y de cuota]
Q --> QC[coste que crece con clientes por consultas]
C --> CC[coste que crece con el numero de cubos]
style T fill:#f9e2af,color:#11111b
style Q fill:#89b4fa,color:#11111b
style C fill:#a6e3a1,color:#11111b

Lo que cuesta tener solo una parte

El primer coste es el de las preguntas que el cliente no puede responder. Un recuento global, una media sobre todo el histórico o un ranking entre elementos que no bajaron son consultas que exigen datos ausentes por definición, y ninguna cantidad de ingenio local las resuelve. La consecuencia no es técnica sino de producto: esos números tendrán que venir del servidor, con su indicador de carga y su posible fallo, justo dentro de una aplicación cuyo argumento principal era haber eliminado ambas cosas. Conviene decidir pronto y por escrito qué cifras son de este tipo, para que aparezcan en la interfaz como lo que son y no como una excepción inexplicable.

El segundo es la contabilidad de solapamientos. En el modelo por consulta, la copia local es la unión de varios conjuntos vivos que se pisan entre sí, así que cerrar una pantalla no autoriza a borrar sus filas: puede que la mitad pertenezca también a otra consulta todavía activa. Hace falta una cuenta de referencias por fila, y hace falta que sea correcta, porque un error por defecto borra datos que otra vista está mostrando y un error por exceso convierte la copia local en un vertedero que solo crece. En el modelo por colección este problema casi desaparece, porque la unidad de retención coincide con la unidad de suscripción.

El tercero es el arranque en frío, y es el que peor se prueba porque los equipos de desarrollo nunca lo sufren: sus dispositivos siempre tienen la copia caliente. El primer arranque de un usuario real es exactamente la situación que este tipo de arquitectura hace peor que la clásica, porque una aplicación convencional muestra la primera pantalla en cuanto llega su respuesta, mientras que una réplica local puede necesitar el conjunto entero antes de ser útil. Es obligatorio medirlo con almacenamiento vacío, con red lenta y con el volumen de datos del percentil noventa y nueve de tus usuarios, no con el tuyo.

Cuando cambian los permisos

Aquí llega el problema que este eje arrastra y que ningún otro plantea. Un permiso revocado no puede quitar de un disco ajeno lo que ya está escrito allí; lo único que puede hacer el motor es enviar una instrucción de borrado y dejar de enviar actualizaciones. Conviene ser explícito con la consecuencia, porque casi siempre se pasa por alto en la fase de diseño y aparece en una auditoría: la revocación en un motor de sincronización es control de acceso continuado, no restauración de confidencialidad. Los datos estuvieron en ese dispositivo, pudieron copiarse, y ninguna instrucción posterior deshace eso. Si la revelación de un dato sería catastrófica en el supuesto de que una revocación futura tuviera que ser efectiva, ese dato no debe sincronizarse nunca.

Aceptado ese límite, la mecánica de la revocación depende por completo de la granularidad elegida, y la comparación es muy instructiva. En el modelo por consulta la revocación es casi gratis, porque el permiso forma parte del predicado: al dejar de cumplirse, la fila sale del conjunto por el mismo camino por el que saldría si alguien la hubiera archivado, y ese camino ya estaba construido y probado. En el modelo por colección es barata y gruesa: el cliente deja de estar suscrito y descarta el cubo entero, lo que es limpio, masivo y a veces excesivo. En la sincronización total es incómoda, porque no existe un mecanismo natural de expulsión y hay que fabricar uno, normalmente una lista de bajas explícitas que el motor no necesitaba para nada más.

El movimiento contrario, la ampliación de permisos, es menos comentado y técnicamente más traicionero. El cliente lleva un punto de reanudación que dice por dónde iba, y lo que acaba de autorizarse pudo cambiar hace meses, muy por detrás de esa marca. Pedir todo lo ocurrido desde el punto actual no traerá nada, porque no ha ocurrido nada nuevo: lo nuevo es el permiso, no el dato. Un motor que no haya previsto esto entrega al usuario una copia local con un agujero silencioso y perfectamente consistente en apariencia.

// Punto de reanudacion unico: la ampliacion de permisos deja un agujero
const cambios = await red.desde(cursorGlobal); // no incluye lo antiguo recien autorizado

// Punto por ambito: lo recien autorizado arranca desde el principio
cursores[nuevoAmbito] = 0;
for (const [ambito, c] of Object.entries(cursores)) {
  const { cambios, siguiente } = await red.desde(ambito, c);
  local.integrar(cambios);
  cursores[ambito] = siguiente;
}

Ese fragmento explica una decisión de diseño que de otro modo parece burocracia: la razón por la que los sistemas basados en colecciones mantienen un punto de reanudación por colección en lugar de uno global no es la comodidad, es que sin él la reincorporación de datos previamente invisibles es incorrecta. Y hay un giro adicional que conviene mirar de frente: la regla que decide el alcance suele depender de datos que también se sincronizan, como la fila que dice a qué equipo perteneces. El alcance depende entonces de un dato que está dentro del alcance, y el motor tiene que tratar los cambios en esas filas como acontecimientos especiales que recalculan la pertenencia, no como una modificación cualquiera.

Cómo elegir el alcance