Un Patrón 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. Unos pocos nodos grandes -- Ciudad de México, Bogotá, Lima -- irradian docenas de conexiones a ciudades más pequeñas. Los nodos grandes son Hubs. Las ciudades pequeñas son Spokes. En lugar de volar directo desde cada ciudad a todas las demás (lo cual requeriría 435 rutas para 30 ciudades), todo el tráfico fluye a través de unos pocos hubs. Menos rutas, más coordinación, mucha más eficiencia.
Punto a punto (arriba) vs Hub-and-spoke (abajo): enrutar a través de un hub central reduce las conexiones drásticamente. Fuente: Wikipedia (dominio público)
La logística funciona igual. FedEx enruta todo por Memphis. Un paquete de Taipei a Kaohsiung podría volar primero a Memphis -- parece absurdo, pero la clasificación centralizada es más eficiente que el relevo punto a punto.
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 el centro de clasificación. Pero en un incidente con víctimas masivas, si el Hub cae, los pacientes no pueden esperar.
El Hub-Spoke de xGrid hace dos modificaciones críticas: cada Spoke es un sistema completo, no solo una terminal. Y — cualquier Spoke puede promoverse a un nuevo Hub en minutos.
El Diseño Físico: Una Columna Vertebral, Muchos Satélites
El despliegue de xGrid es una topología escalable construida alrededor de un switch Ethernet:
┌─────────────────────┐
│ Hub A │
│ CIRS + MIRS + HIRS │
│ WiFi Hotspot │
│ mDNS broadcast │
└──────────┬──────────┘
│
┌─────────┴─────────┐
│ Ethernet Switch │
└──┬────┬────┬────┬─┘
│ │ │ │
┌──┴┐┌──┴┐┌──┴┐┌──┴┐
│ B ││ C ││ D ││ E │ ← Spokes
└───┘└───┘└───┘└───┘
Cada uno con su propio WiFi hotspot
Cada uno ejecuta MIRS completo
Cada uno mantiene un snapshot reciente de CIRS
El Hub ejecuta el sistema de recursos (CIRS), el sistema clínico (MIRS) y el inventario (HIRS). Los Spokes se conectan al Hub a través de un switch Ethernet, cada uno ejecutando MIRS para administrar el inventario de su propia estación.
Dos capas de red separadas, por diseño: Ethernet para sincronización de datos entre estaciones. WiFi para operaciones clínicas dentro de cada estación. Una puede fallar sin afectar a la otra.
Cada RPi Es un Sistema Completo — La Imagen Dorada
Esta es la decisión de diseño más importante de toda la arquitectura: cada Raspberry Pi viene con todo preinstalado.
CIRS (recursos), MIRS (clínico), HIRS (inventario) — todos presentes en cada tarjeta SD. El rol no lo determina el hardware. Lo determina un único archivo de configuración: /etc/xgrid/role.conf. Cambie un campo y un Spoke se convierte en Hub.
Esto significa que no necesita almacenar "unidades Hub" y "unidades Spoke." Almacena repuestos idénticos. Cualquier unidad puede reemplazar a cualquier otra.
Despliegue por Niveles — Desde Estación Avanzada hasta Centro Médico
| Nivel | Configuración | Conectividad | Tablets simultáneas |
|---|---|---|---|
| Centro Médico | 1 Hub + 4 Spokes | Switch de 8 puertos | ~75 |
| Hospital Regional | 1 Hub + 3 Spokes | Switch de 5 puertos | ~60 |
| Hospital Distrital | 1 Hub + 1 Spoke | Cable directo | ~30 |
| Estación Avanzada | 1 Independiente | No requerido | ~15 |
La misma Imagen Dorada funciona en todos los niveles. La diferencia es cuántas unidades despliega y qué roles les asigna — no qué software llevan.
La Desconexión No Es Falla — Es el Estado Esperado
En xGrid, perder el enlace de red no dispara nada visible para el personal clínico. Ambos sistemas continúan operando con funcionalidad completa — sus propias bases de datos, sus propias interfaces clínicas, sus propias estaciones de tabletas.
Principio de diseño fundamental: cada Spoke es un sistema completo. El Hub proporciona coordinación, no capacidad. Cuando se pierde la coordinación, lo único que cambia es el momento de la sincronización.
Sincronización en Tres Fases
Fase 1 — Verificar: El Hub verifica la salud de cada Spoke. Sin respuesta en 30 segundos — omitir. Una verificación de alineación de reloj asegura que ambos dispositivos coincidan en la hora actual. Si difieren en más de 30 segundos, la sincronización se rechaza para prevenir corrupción de timestamps.
Fase 2 — Push (Hub a Spokes): Eventos clínicos fluyen hacia afuera. El Hub envía un snapshot completo de CIRS a cada Spoke cada cinco minutos. Estos snapshots se almacenan localmente en cada Spoke — las 12 copias más recientes, una ventana de respaldo rotativa de una hora.
Fase 3 — Pull (Spokes a Hub): Eventos de recursos fluyen hacia adentro: cambios de inventario, operaciones de banco de sangre, registros quirúrgicos, bitácoras de dispensación.
Seis Estrategias de Resolución de Conflictos
| Estrategia | Tipos de datos | Lógica |
|---|---|---|
| Agregar ambos | Signos vitales, traspasos, dispensación | Eventos inmutables — conservar ambas versiones |
| Más reciente gana | Datos demográficos del paciente | Comparar timestamps, la más reciente prevalece |
| Hub gana | Registros, prescripciones, cirugías | CIRS (Hub) es autoritativo |
| Sumar ambos | Cantidades de inventario | Sumar el consumo de ambos lados |
| Siempre bloquear | Productos sanguíneos, sustancias controladas | Nunca resolver automáticamente — requiere verificación humana |
| In-situ gana | Estado de equipos | El operador presente físicamente tiene precedencia |
Sumar ambos para inventario: El Hub consumió 5 vendas, el Spoke consumió 3. La respuesta correcta es 5 + 3 = 8 consumidas.
Siempre bloquear para productos sanguíneos: Una unidad de sangre marcada como "emitida" en ambas estaciones simultáneamente no puede resolverse con ninguna regla automática. Alguien necesita verificar físicamente dónde está esa unidad.
Desconectar y Listo — Spoke Se Promueve a Hub
Esta es la capacidad más poderosa de la arquitectura.
Usted está operando un despliegue de 1 Hub + 3 Spokes en un incidente con víctimas masivas. Dos horas después, el comandante reporta un segundo punto de recolección a diez kilómetros. Necesita una estación médica funcionando allí ahora.
Camina hacia uno de los Spokes. Desconecta el cable Ethernet. Lo empaca en una bolsa con una batería y un iPad. Conduce al nuevo sitio. Conecta la energía. Por SSH ejecuta un comando:
sudo xgrid-promote
El proceso de promoción es una máquina de estados atómica. Si cualquier paso falla, toda la operación se revierte — la unidad regresa al modo Spoke.
Cuando tiene éxito, el iPad se conecta a la nueva red WiFi, abre la PWA, y usted está viendo una estación médica completamente operativa con datos de pacientes del Hub original — con máximo cinco minutos de antigüedad.
Hub Caído — Toma de Control en Cinco Minutos
Cada Spoke monitorea continuamente el heartbeat del Hub — cada 30 segundos. Tres fallos consecutivos (90 segundos de silencio) activan un banner rojo: "Hub fuera de línea."
Un operador decide: ¿qué Spoke toma el control? El script de promoción carga el snapshot latest.good — un enlace simbólico que siempre apunta al respaldo verificado más reciente.
La pérdida máxima de datos del paciente es cinco minutos — el intervalo entre envíos de snapshots.
¿Por qué no promover automáticamente? Porque en un entorno desconectado, no se puede distinguir entre "el Hub fue destruido" y "el cable Ethernet está suelto." La promoción automática arriesga crear dos Hubs que ambos creen que están a cargo — una condición de split-brain. La promoción debe ser una decisión humana.
Protección contra Split-Brain — Epochs, No Confianza
Cada vez que un Spoke se promueve a Hub, el contador epoch se incrementa. El epoch está incrustado en cada snapshot, cada broadcast mDNS, cada handshake de sincronización.
Detección de zombis. Hub A (epoch 1) cae y Spoke B se promueve (epoch 2). Alguien reconecta Hub A. Al iniciar, escanea la red y descubre un Hub transmitiendo epoch 2 — mayor que su epoch 1. Hub A se degrada automáticamente a Spoke.
Validación de Spoke. Si un Spoke encuentra dos Hubs con diferentes epochs, levanta una alerta naranja y se rehúsa a reconectarse automáticamente hasta que un humano resuelva la ambigüedad.
Aislamiento de clúster. Cada despliegue lleva un cluster_id único. Los Spokes solo aceptan Hubs con cluster_id coincidente.
Descubrimiento de Servicios — Sin IPs Fijas
xGrid usa mDNS (multicast DNS) vía avahi-daemon. Cuando un Hub inicia, transmite _xgrid-hub._tcp en la red local. Los Spokes escuchan esta transmisión. Cuando detectan un nuevo Hub con cluster ID válido y epoch mayor, actualizan su objetivo de conexión automáticamente.
Sin archivos de configuración que actualizar. Sin direcciones IP que recordar. La red se describe a sí misma.
Headless — Su iPad Es el Panel de Control
Los Raspberry Pi de xGrid nunca tienen monitores. Nunca tienen teclados. Todo el trabajo clínico ocurre a través de PWAs sobre WiFi. La administración del sistema ocurre por SSH.
Hardware total por estación: un Raspberry Pi, un cable de energía, un cable Ethernet (si no es independiente). La huella de despliegue cabe en una mochila.
Consolidación de Estaciones — Cuando un Sitio Evacúa
Cuatro modos de fusión manejan diferentes escenarios:
- Fusión completa: Todos los datos fluyen a la estación destino
- Fusión parcial: Solo categorías seleccionadas se transfieren
- Importación de respaldo: Restaurar desde respaldo portátil
- Cierre de emergencia: Apagado con preservación completa de datos
Cada fusión registra exactamente qué se movió. Esta pista de auditoría responde la pregunta que siempre surge después del desastre: "Cuando esa estación evacuó, ¿a dónde fue todo?"
Diseñando para la Desconexión
La mayoría de los sistemas distribuidos parten de la premisa "la red es confiable" y agregan manejo de excepciones para cuando no lo es.
xGrid parte de la premisa "la red no es confiable" y optimiza para cuando funciona.
Esta inversión produce un diseño fundamentalmente diferente:
- Cada nodo es un sistema completo (no un cliente ligero que depende de un servidor)
- Cada unidad viene con todo el software preinstalado (el rol es un archivo de configuración)
- Cualquier Spoke puede promoverse a Hub
- La sincronización es batch periódico (no streaming en tiempo real)
- La resolución de conflictos es el comportamiento por defecto
- Los Hubs obsoletos se degradan solos (porque el epoch counter es un hecho, no una política)
El cable será pateado. El switch será derribado de la mesa. El Hub recibirá un golpe.
Ninguno de estos es un modo de falla. Son transiciones de topología.
Relacionado: Offline-First Is Not a Fallback · ISBAR Is More Than a Handoff Format