El patrón de reserva: una pestaña líder y workers dedicados

Las tres lecciones anteriores dejan el terreno despejado: el worker compartido resuelve el problema pero no está garantizado, el canal de difusión avisa pero no arbitra, y el Service Worker es único pero no permanece. Lo que queda es construir a mano la propiedad que el worker compartido te regalaba, y hacerlo apoyándose en la única pieza de la plataforma que puede sostenerla, que es la API de bloqueos, porque es la única que observa de verdad la muerte de una pestaña en lugar de inferirla. El resultado es un patrón con nombre propio —pestaña líder con workers dedicados— que llevan dentro casi todas las bibliotecas serias de almacenamiento en el cliente, y que conviene entender pieza a pieza porque es el mismo esqueleto que reaparecerá, a escala planetaria, en la parte de sincronización de este track.

La forma del patrón

Todas las pestañas arrancan su propio worker dedicado, porque un worker dedicado está disponible siempre y aísla el trabajo pesado del hilo de interfaz. Lo que distingue al líder no es tener worker, sino abrir la base. El worker del líder es el único que toca IndexedDB o OPFS; los de las seguidoras se limitan a hacer de proxy, empaquetando las peticiones de su pestaña y esperando la respuesta que llegue desde el otro lado.

flowchart TB
L[Pestana lider] --> WL[Worker dedicado que abre la base]
WL --> D[IndexedDB u OPFS]
S1[Pestana seguidora 1] --> W1[Worker proxy]
S2[Pestana seguidora 2] --> W2[Worker proxy]
W1 -->|peticion| WL
W2 -->|peticion| WL
WL -->|respuesta y avisos| W1
WL -->|respuesta y avisos| W2
style WL fill:#cba6f7,color:#11111b
style D fill:#a6e3a1,color:#11111b

Antes de seguir conviene descartar la simplificación que todo el mundo intenta: dejar que la pestaña líder abra la base en su propio hilo principal y ahorrarse un worker. Falla por tres motivos independientes. El primero es que devuelve al hilo de interfaz el trabajo pesado que el nivel anterior sacó de ahí, y ahora multiplicado, porque el líder atiende además las peticiones de las demás. El segundo es que la parte más exigente de OPFS solo está disponible fuera de la ventana, de modo que ni siquiera es una opción si tu capa la usa. Y el tercero es el que más duele en producción: el hilo principal de una pestaña de fondo se ralentiza de forma agresiva, así que el líder atendería a las seguidoras a paso de tortuga precisamente cuando el usuario está trabajando en otra de ellas.

Que las seguidoras conserven su worker no es simetría estética: es lo que permite que el relevo sea barato. Cuando el líder muere y otra pestaña toma el mando, esa pestaña no tiene que arrancar un contexto nuevo ni cargar el motor desde cero; su worker ya está caliente y solo cambia de papel, de proxy a dueño. Un diseño donde la seguidora no tiene worker convierte cada relevo en un arranque completo justo en el momento de máxima urgencia.

La elección y la muerte del líder

El mecanismo es un bloqueo exclusivo con un nombre acordado y una promesa que jamás se resuelve. Suena a truco y no lo es: el bloqueo se sostiene mientras dure la función que lo recibió, así que no terminar nunca es la forma canónica de decir “soy el líder hasta que muera”.

const miId = crypto.randomUUID();
let epoca = 0;

async function competirPorElLiderazgo() {
  await navigator.locks.request('datos-lider', { mode: 'exclusive' }, async () => {
    epoca = await incrementarEpocaPersistida();   // contador monotono en disco
    await abrirBaseEnMiWorkerConEspera();         // OPFS puede tardar en soltarse
    await guardarLiderEnDisco({ id: miId, epoca });
    anunciar({ tipo: 'lider', id: miId, epoca });
    await new Promise(() => {});                  // retener mientras viva
  });
}

Lo que hace viable todo el patrón es una única propiedad: cuando la pestaña que sostiene el bloqueo desaparece —cerrada, caída, aniquilada por el sistema por falta de memoria—, el navegador lo libera solo, sin cooperación de ningún código, y la siguiente petición de la cola entra automáticamente. Ninguna aplicación puede darse esa garantía a sí misma, por las razones que la lección 3 desarrolló: desde dentro de un documento no se puede distinguir a un muerto de un lento. El navegador sí puede, porque es él quien destruye los documentos.

Quedan dos asperezas que hay que tratar con nombre propio. La primera es que el nuevo líder puede encontrarse el fichero todavía retenido por el manejador del anterior, que se libera al destruirse su worker y no en el mismo instante en que se soltó el bloqueo; por eso la apertura lleva reintentos con espera creciente y no una única tentativa. La segunda es el líder zombi: una pestaña congelada en la caché de retroceso puede haber perdido su bloqueo y despertar minutos más tarde convencida de que sigue mandando, con peticiones a medio camino.

// Vallado por epocas: rechazar sin discutir lo que llega de un mando caducado
function atender(peticion) {
  if (peticion.epoca < epocaActual) {
    return { error: 'EPOCA_CADUCADA', epocaActual };
  }
  return ejecutar(peticion);
}

El enrutado, sus dos saltos y su factura

Con el líder elegido queda transportar peticiones. Hay dos rutas, y elegir bien tiene consecuencias medibles. La ruta simple usa el canal de difusión con sobres identificados; funciona en todas partes y tiene el defecto conocido de que cada mensaje se clona para todas las pestañas, incluidas las que no tenían nada que ver. La ruta buena establece un canal privado por seguidor, con un extremo de canal entregado por el Service Worker según la centralita de la lección anterior, y reduce el tráfico a los dos interesados.

// Cliente: promesas pendientes indexadas por identificador de operacion
const pendientes = new Map();

function pedir(operacion) {
  const idOp = operacion.idOp ?? crypto.randomUUID();   // estable entre reintentos
  return new Promise((resolve, reject) => {
    pendientes.set(idOp, { resolve, reject, operacion });
    puertoAlLider.postMessage({ ...operacion, idOp, epoca: epocaConocida });
  });
}

function alRecibir(respuesta) {
  const p = pendientes.get(respuesta.idOp);
  if (!p) return;                       // duplicado tardio: ignorar
  pendientes.delete(respuesta.idOp);
  respuesta.error ? p.reject(respuesta.error) : p.resolve(respuesta.dato);
}

La factura de este diseño hay que mirarla de frente en lugar de descubrirla en producción. Una consulta desde una pestaña seguidora recorre cuatro fronteras de clonado estructurado en la ida y la vuelta: de su hilo principal a su worker, de su worker al del líder, y los dos saltos simétricos al regresar. Eso convierte una lectura que en el líder cuesta décimas de milisegundo en algo perceptiblemente más caro para las demás pestañas, y sugiere tres correctivos que conviene aplicar desde el principio: agrupar peticiones en lotes en lugar de emitirlas de una en una, devolver resultados en formatos que se clonen barato, y mantener en cada seguidora una caché de solo lectura alimentada por los avisos del líder, para que la mayoría de las lecturas ni siquiera crucen la frontera.

Lo que queda abierto para el nivel siguiente

El esqueleto ya está completo, pero la pieza sobre la que se apoya se ha usado aquí en su forma más elemental. El nivel 18 desarma la API de bloqueos entera: los dos modos, compartido y exclusivo, que permiten distinguir a muchos lectores de un solo escritor; la petición que no espera si el recurso está ocupado, que es la forma correcta de preguntar si ya hay líder sin quedarse encolado; la cancelación mediante señal, que evita colas infinitas de aspirantes; la consulta del estado de los bloqueos, que da un censo real de titulares y pretendientes; y la disciplina de arrendamientos con renovación, para los casos en que retener un bloqueo indefinidamente no es aceptable. Con esas herramientas, la elección casera de esta lección se convierte en un protocolo con propiedades enunciables.

Queda además una pregunta que este nivel deja abierta a propósito y que el siguiente responde con datos: si el patrón de reserva funciona en todas partes, ¿merece la pena seguir manteniendo la rama del worker compartido? La respuesta razonable es que sí, y no por elegancia, sino porque ahorra un salto de mensajes a todas las pestañas y elimina de raíz el relevo y su ventana sin servicio. Pero exige la disciplina que ya señalaba la lección 2: una única interfaz, dos implementaciones detrás, y la batería de pruebas ejecutándose completa en ambas configuraciones. Una rama que no se prueba no es una optimización, es una segunda aplicación que se estropeará sin que nadie lo note.