Hace poco me tocó resolver un problema raro: en un sistema distribuido, hay un punto que no debería ser un cuello de botella, pero lo es. Y ese punto es precisamente el que necesitas para que todo funcione.

Se llama AgoraHub.

El problema sin un nodo central

Imagina un ecosistema donde los usuarios abren terminales en contenedores Docker distribuidos. Donde los agentes de IA ejecutan comandos. Donde los browsers hablan con workers. Donde todo se mueve asincronía y en paralelo.

Sin un coordinador, tendrías que resolver esto:

  • Browser A quiere ejecutar un comando. ¿A qué worker se lo envía?
  • Worker B necesita saber si hay sesiones PTY activas en este workspace. ¿Quién lleva ese estado?
  • Agente C quiere correr una batería de comandos. ¿Cómo garantiza que se ejecutan en el orden correcto y que recibe las respuestas de vuelta?

La respuesta ingenua es: cada cliente conoce a todos los demás. Peer-to-peer puro.

Eso funciona hasta que tienes 40 workers, 12 browsers simultáneos, un agente IA con ritmo propio y rutas de red impredecibles. En ese punto, no estás coordinando un sistema. Estás administrando el caos.

La herejía del nodo que escucha todo

Entonces llega AgoraHub. Un solo servicio socket.io que corre en un VPS Hostinger en Estados Unidos, con Caddy delante, protegido con HTTPS. Un único punto de escucha donde todo converge.

Y aquí está la paradoja: para construir un sistema distribuido, necesitas un punto central que no es distribuido.

Es como el experimento de Milgram sobre grados de separación: si todos tratan de conectarse directamente con todos, la malla se vuelve imposible de rastrear. Pero si hay un nodo que sabe a quién conectar con quién, de repente el caos se colapsa en estructura.

AgoraHub no procesa. No calcula. Solo escucha.

Recibe eventos de browsers: "quiero una sesión PTY". Recibe heartbeats de workers: "aquí estoy, vivo". Recibe órdenes del agente: "ejecuta esto". Y mantiene un estado en memoria: ¿quién está conectado? ¿qué sesiones activas hay? ¿qué comandos están pendientes?

Cuando un browser necesita alcanzar un worker, AgoraHub lo sabe. Cuando un worker necesita informar, AgoraHub escucha. Cuando el agente IA necesita saber si un comando terminó, AgoraHub le devuelve el estado.

Es un demonio de coordinación disfrazado de servidor trivial.

La fragilidad del conocimiento centralizado

Lo incómodo es que AgoraHub es un punto de fallo. No es un almacenamiento persistente (perderías el estado si reinicia). Es un coordinador de sesiones efímeras. Cada reconexión requiere que los clientes sepan volver a suscribirse.

Pero aquí es donde el diseño es sobrio: en vez de pretender que el nodo es indestructible, asume que será destruido. Los browsers saben que si pierden la conexión, deben reconectar y re-suscribirse a su workspace. Los workers conocen la URL del hub y saben reintentarlo.

El estado en memoria se pierde. Pero la arquitectura está diseñada para que eso no sea catastrófico. Es aceptar la fragilidad como premisa, no como un defecto oculto.

Qué aprendí de esto

Construir un sistema distribuido no es construir un mapa de máquinas autónomas. Es diseñar una arquitectura donde el caos local (cada agente persigue su objetivo) converge en orden global (el nodo central mantiene la vista).

El anti-patrón es construir el nodo central como si fuera eterno. El patrón es construirlo como si fuera temporal, y hacer que los clientes sean lo suficientemente inteligentes para vivir sin él.

AgoraHub enseña algo más profundo: hay problemas de coordinación que no se resuelven con más descentralización. Se resuelven con un nodo que admite sus limitaciones y construye todo lo demás alrededor de eso.

Es la misma razón por la que la democracia necesita un ejecutivo, aunque el ejecutivo sea una contradicción de la autonomía. Es la misma razón por la que los equipos de ingeniería necesitan un líder técnico, aunque el liderazgo técnico es incompatible con la igualdad.

Algunos puntos de orden no son defectos de un sistema. Son su estructura ósea.

— Steven Vallejo, Medellín