Empecemos por un Hub-Spoke que usted ya conoce
Quizá no haya escuchado el término "topología Hub-Spoke," pero lo usa todos los días.
Abra el mapa de rutas de cualquier aerolínea. Verá unos pocos nodos enormes —Ciudad de México, Bogotá, Lima— de los que irradian decenas de rutas que conectan a docenas de ciudades más pequeñas. Los nodos grandes son los Hubs (centros). Las ciudades pequeñas son los Spokes (radios).
Punto a punto (arriba) vs Hub-Spoke (abajo): al reenviar a través de un nodo central, se reduce drásticamente el número de conexiones. Fuente: Wikipedia (dominio público)
¿Por qué las aerolíneas diseñan así? Porque si cada ciudad volara directo a todas las demás, 30 ciudades necesitarían 435 rutas. Pero si todas vuelan primero al Hub y desde allí hacen escala, bastan 30 rutas. El Hub es el coordinador: centraliza la planificación, las conexiones y la asignación de recursos.
Este patrón también es muy común en los sistemas de información: un nodo central coordina varios nodos en el borde. Los datos se concentran en el Hub, y los Spokes se encargan de las operaciones de primera línea.
Pero el Hub-Spoke tradicional tiene una suposición fatal: el Hub siempre está en línea.
Los vuelos pueden esperar a que el aeropuerto Hub reabra. Los paquetes pueden esperar a que el centro de clasificación los procese. Pero en un desastre, si el Hub cae, los pacientes no pueden esperar.
El Hub-Spoke de xGrid introduce dos cambios conceptuales clave: cada Spoke es un sistema completo, no solo una terminal. Y además —cualquier Spoke puede tomar el relevo en el sitio y convertirse en el nuevo Hub.
La desconexión no es una falla, es el estado esperado
Los sistemas tradicionales tratan la pérdida de red como una "falla": detectan la desconexión, disparan una alerta y esperan la recuperación.
xGrid diseña la desconexión como algo "normal." Cada dispositivo es un sistema completo: con su propio sistema de recursos, su propia base de datos. La desconexión solo significa perder temporalmente la capacidad de sincronizar, no la capacidad de operar.
Esta es la mayor diferencia entre el Hub-Spoke de xGrid y el de las aerolíneas: el Spoke no es una terminal que espera órdenes del Hub, sino un sistema completo capaz de operar de forma independiente. Lo que el Hub aporta es coordinación, no capacidad.
Cada nodo es un sistema completo
Este es el concepto más crucial de todo el diseño: cada dispositivo sale de fábrica siendo una estación médica completa.
El rol no lo determina el hardware. La misma máquina puede ser Hub o puede ser Spoke: la diferencia está en el papel que desempeña, no en las piezas que la componen. Esto significa que no necesita preparar "máquinas para Hub" y "máquinas para Spoke." En el almacén no guarda "dos tipos de piezas," sino "un montón de repuestos idénticos." Si una falla, saca una nueva de la caja, la conecta y sigue.
El despliegue mínimo solo requiere una máquina, sin ninguna infraestructura de red: una fuente de energía y una tableta ya son una estación médica completa. ¿Necesita ampliar? Traiga otra máquina y conéctela: se convierte en un nuevo Spoke. Una sola máquina puede sostener una estación médica avanzada; un conjunto de máquinas puede sostener un centro médico. El mismo diseño, escalando según la magnitud.
Dos redes independientes — cuando una cae, la otra sostiene
El despliegue de xGrid son dos redes independientes superpuestas: una se encarga de las operaciones (cada máquina ofrece su propia cobertura inalámbrica, y la tableta trabaja conectándose a la más cercana), y la otra se encarga de la sincronización entre estaciones.
La clave es que estas dos capas son completamente independientes. ¿Cae la capa de sincronización? Las tabletas de cada estación siguen operando; solo se pierde temporalmente la sincronización entre estaciones. ¿Falla la cobertura inalámbrica de una máquina? La sincronización sigue su curso, y las tabletas de esa zona simplemente se conectan a una cobertura cercana.
Cuando una capa cae, la otra sostiene. Así se materializa, en el diseño de red, el principio de que "la desconexión es el estado esperado."
Cualquier Spoke puede tomar el relevo
Esta es la capacidad más poderosa de todo el diseño, y tiene dos formas.
Llevárselo activamente. En un incidente con víctimas masivas, el centro de mando avisa que ha aparecido un segundo punto de concentración de heridos a diez kilómetros y que hace falta abrir de inmediato una segunda estación médica. Usted se acerca a uno de los Spokes, lo guarda en una mochila junto con la batería y la tableta, llega al nuevo lugar y conecta la energía: se convierte en una estación médica nueva, completa y autónoma, que lleva consigo todos los datos de pacientes que el Hub original tenía hasta hace poco. No hace falta planificación previa ni máquinas especiales.
Tomar el relevo pasivamente. El hardware del Hub falla: se quemó la fuente, lo golpeó un trozo de techo que cayó. Cada Spoke vigila de forma continua si el Hub sigue presente. Una vez confirmado que el Hub está realmente fuera de línea, el operador designa a uno de los Spokes para que tome el relevo. Como cada Spoke conserva una copia casi en tiempo real, la pérdida de datos de pacientes al tomar el relevo tiene un límite claro; en el pico de llegada de heridos, el operador incluso puede bajar manualmente ese límite aún más.
La toma de relevo es una operación de todo o nada: o se completa por entero, o se vuelve al estado original; nunca queda un resultado a medias "atascado a mitad de camino."
¿Por qué es una decisión humana y no automática de la máquina? Porque en un entorno sin red no puede estar seguro de si el Hub está realmente averiado o si solo se aflojó el cable. Si dos Spokes tomaran el relevo automáticamente al mismo tiempo, tendría dos Hubs atendiendo pacientes cada uno por su cuenta: eso se llama split-brain, y fusionar los datos después sería un desastre. Por eso la toma de relevo debe ser una decisión humana deliberada.
Hubs zombi y protección contra el split-brain — por mecanismo, no por disciplina
"No promover dos máquinas al mismo tiempo" es una regla. Pero las reglas se rompen en un desastre: ¿y si en medio del caos alguien pulsa una vez de más?
Por eso la disciplina por sí sola no basta. El diseño de xGrid hace que el Hub obsoleto ceda su lugar por sí mismo: cuando un Hub antiguo que se había averiado vuelve a encenderse tras reconectarse a la energía, descubre que en el sitio ya hay un Hub "una generación más reciente" en funcionamiento; en lugar de intentar recuperar el mando, se degrada automáticamente a Spoke. Nadie tiene que ir a apagarlo.
Del mismo modo, si un Spoke, al reconectarse, ve dos "estaciones principales" contradictorias a la vez, no elige una al azar, sino que se detiene y pide confirmación humana. Cada despliegue está además aislado de los demás: su Spoke no se conectará por accidente al Hub del despliegue vecino.
Este mecanismo no puede prevenir el split-brain al cien por cien: si dos subgrupos totalmente aislados toman el relevo cada uno con su propio Hub, efectivamente acabará con dos Hubs independientes. Pero garantiza una cosa: en el instante en que esos dos subgrupos vuelvan a conectarse a la red, el más antiguo cederá su lugar automáticamente. El problema nunca fue "cómo prevenir el split-brain para siempre," sino "cómo corregirlo automáticamente lo más rápido posible una vez ocurrido."
Resolución de conflictos: depende de la naturaleza del dato
Dos dispositivos, durante la desconexión, modifican cada uno el mismo dato. Al reconectarse, ¿qué se hace?
La respuesta depende de qué sea el dato. Lo que se puede acumular, se acumula: la estación principal consumió 5 vendas y la estación satélite consumió 3; la respuesta correcta es que se consumieron 8, y no "que prevalezca la más reciente" (eso perdería una de las dos). Los registros inmutables (signos vitales, traspasos) se conservan en ambos lados.
Lo más importante son aquellos datos cuyo error tiene un costo demasiado alto y no se permite resolver automáticamente: bolsas de sangre, sustancias controladas. Una bolsa de sangre marcada como "emitida" en dos estaciones a la vez no es un problema que se resuelva con una marca de tiempo. El sistema lo marca como conflicto y espera a que el personal responsable lo verifique en persona.
Tratar el "juicio humano" como la respuesta correcta en ciertas situaciones, y no como un defecto a eliminar, es la distinción clave al diseñar para entornos de alto riesgo.
Filosofía de diseño: pensado para la desconexión
La mayoría de los sistemas parten de la premisa de que "la red es confiable" y luego añaden un manejo de excepciones para los casos en que no lo es.
xGrid parte de la premisa de que "la red no es confiable" y luego optimiza para los casos en que sí lo es.
Esta inversión conduce a decisiones de diseño completamente distintas:
- Cada nodo es un sistema completo (no una terminal que solo muestra una pantalla)
- El rol lo determina el papel que se desempeña, no el hardware (no hacen falta "máquinas Hub especiales")
- La sincronización es una operación por lotes periódica (no una conexión continua en tiempo real)
- La resolución de conflictos es el comportamiento por defecto (no un manejo de excepciones)
- El juicio humano es la respuesta correcta en ciertas situaciones (no un defecto a eliminar)
- La toma de relevo es una decisión humana deliberada (porque el split-brain es más peligroso que esperar)
- Pero el Hub obsoleto cede su lugar automáticamente (porque eso es un hecho, no una cuestión de disciplina)
Que pateen el cable no es una falla. Que destrocen el switch no es el apocalipsis. Que el Hub se queme no es el final.
Solo son los detonantes de una reorganización de la topología.
Lecturas relacionadas: «Offline-first» no es «apenas usable sin conexión» · ISBAR es más que un formato de traspaso — cuando la tradición oral se encuentra con los datos estructurados