Con una cuenta desbloqueas el cuestionario, el foro de dudas y el tutor con IA de esta lección, además del registro de progreso y el certificado verificable al terminar «Sistemas Distribuidos para Misiones Espaciales».
Un broker de mensajería dedicado — Kafka, MQTT, RabbitMQ/AMQP — resuelve problemas reales: entrega garantizada a gran escala, orden estricto dentro de una partición, replay masivo de historia. Pero también es otra pieza de infraestructura que operar: otro proceso que vigilar, otra dependencia que puede caerse, otro punto donde algo puede fallar de una forma nueva. Para un clúster de seis aplicaciones con un volumen de eventos modesto, instalar y operar un broker dedicado es, con honestidad, sobre-ingeniería.
La alternativa: un bus HTTP sobre el hub
El clúster resuelve la comunicación de eventos con un bus construido sobre el propio hub de registro, usando HTTP simple y ofreciendo dos modos de consumo de primera clase, no uno con el otro como excepción:
Webhook firmado (push): el hub entrega el evento llamando directamente al endpoint que la app consumidora registró, firmando la llamada para que el receptor pueda verificar que de verdad viene del hub (la lección 5 detalla la firma HMAC).
Polling con cursor (pull): la app consumidora hace GET /events?since=<seq> cuando le conviene, y avanza su propio cursor (seq) a medida que procesa. Este modo no es un respaldo de segunda clase del webhook: es la única vía viable para consumidores que están detrás de NAT (sin IP pública a la que el hub pueda llamar) o para aplicaciones de escritorio que no exponen ningún puerto — situaciones reales y frecuentes en un clúster con una estación terrena en una red doméstica.
El sobre (envelope) de un evento
Todo evento que circula por el bus se envuelve en una estructura común, independientemente de qué datos concretos lleve:
El id es un UUID único del evento (crítico para la deduplicación de la lección 4); type usa un dominio con puntos (pass.completed, no un string libre) para que los consumidores puedan filtrar por familia de eventos; source identifica qué app lo publicó; time es la marca temporal del hecho; y data es el payload concreto, validado contra el contrato JSON Schema correspondiente a ese type (lección 2) antes de aceptarse.
Fan-out y anti-suplantación
Cuando se publica un evento, el hub hace fan-out: lo entrega (por webhook) o lo pone a disposición (por polling) de todos los consumidores suscritos a ese type, no solo a uno. La seguridad de ese fan-out depende de una comprobación simple pero esencial: el source declarado en el evento debe coincidir con la identidad de la clave de API que lo publica. Si la clave del clasificador de señales intentara publicar un evento con source: "estacion-orbiteye-mx", el hub lo rechaza — sin esa comprobación, cualquier app con una clave válida podría suplantar a cualquier otra y publicar eventos falsos en su nombre.
Cuándo SÍ necesitas un broker de verdad
Este bus HTTP no es la respuesta correcta para siempre. La señal de que hace falta un broker dedicado aparece cuando el volumen de eventos supera lo que un polling razonable puede sostener, cuando se necesita orden estricto garantizado dentro de un flujo (no solo un seq creciente que un consumidor puede leer fuera de orden si se retrasa), o cuando se necesita replay masivo de historia completa para reprocesar datos antiguos a gran escala. Reconocer esa frontera — y no instalar Kafka "por si acaso" — es tan parte de la ingeniería como construir el bus simple.
Visualicemos el mismo evento viajando por ambos modos:
¿En qué situación el polling con cursor es la ÚNICA vía viable para consumir un evento del bus?
El laboratorio de esta lección simula el bus completo: publica eventos, observa cómo el hub hace fan-out hacia tres consumidores distintos (uno por webhook, uno por polling, uno desconectado tras NAT que solo puede usar polling), e intenta suplantar un source ajeno para ver el rechazo en acción.
Laboratorio: Simulador del bus de eventos: push, pull y anti-suplantación
8. Custodia de datos: un backup no probado no es backup