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».
Este curso no es un ejercicio de laboratorio: es la descripción honesta de un clúster que existe y opera hoy. Seis aplicaciones en producción componen el ecosistema CODE Aerospace: un hub de registro (el directorio central donde cada app se da de alta), dos gemelos digitales de misión (uno orbital, otro de un sistema de apuntamiento en tierra), una estación terrena que recibe satélites de verdad, un clasificador de señales basado en aprendizaje automático, y un plano de gobernanza experimental donde se prueban ideas antes de llevarlas al resto. Cada una tiene su propio dominio, su propia base de datos y su propio despliegue: no comparten servidor, no comparten esquema, no comparten ciclo de vida.
A lo largo del curso volveremos una y otra vez a este mismo clúster como caso de estudio continuo — incluyendo sus trade-offs, sus decisiones discutibles y las cosas que cambiaríamos si empezáramos de nuevo. La honestidad sobre lo que funciona y lo que es un compromiso pragmático es parte del contenido, no una nota al margen.
El hub es un registro, no un intermediario
La decisión de diseño más importante del clúster es esta: el hub central es un directorio de descubrimiento, no una capa de intermediación. Cuando la estación terrena necesita avisarle al clasificador que hay una nueva grabación, no le pide al hub que reenvíe el mensaje en tiempo real como un proxy — consulta al hub una vez para descubrir la URL base y la clave de API del clasificador, y a partir de ahí habla directamente con él. El hub participa en el descubrimiento de la arista, no en cada mensaje que viaja por ella.
La consecuencia práctica es enorme: si el hub se cae, las conexiones ya establecidas siguen funcionando exactamente igual. Un satélite en pase no deja de ser rastreado porque el hub esté reiniciando. Lo único que se degrada durante una caída del hub es el descubrimiento de aristas nuevas — una app que arranca por primera vez, o que necesita rotar una clave, tendrá que esperar. Esa es una degradación aceptable; un hub que fuera intermediario convertiría cada mensaje del clúster en un punto único de fallo.
El catálogo de acoplamientos que matan sistemas distribuidos
La mayoría de los sistemas distribuidos no fallan por falta de funcionalidades: fallan porque, con el tiempo, dos componentes que deberían ser independientes terminan acoplados de una forma que nadie diseñó a propósito. Este curso usa un catálogo de seis acoplamientos recurrentes, numerados A1–A6, para nombrarlos y así poder detectarlos antes de que se vuelvan deuda técnica:
A1 — Redes de contenedores compartidas: dos apps en la misma red Docker interna "porque es más fácil" — ahora ninguna puede desplegarse de forma aislada ni migrar de host sin romper a la otra.
A2 — DNS de contenedor: una app resuelve a otra por su nombre de contenedor (http://otra-app:puerto) en vez de una URL pública estable — funciona en desarrollo y se rompe en cuanto cambia la topología de despliegue.
A3 — host.docker.internal: un atajo de desarrollo que se filtra a producción y asume que ambas apps viven siempre en el mismo host físico.
A4 — Filesystem compartido: una app escribe un archivo que otra lee directamente del disco, sin ninguna API entre medio — cualquier cambio de formato rompe al consumidor sin previo aviso, y sin control de acceso.
A5 — Descubrimiento por conocimiento previo hardcodeado: una URL o una clave copiada y pegada en el código fuente de la otra app — rotar la clave implica desplegar dos apps a la vez, coordinadas manualmente.
A6 — Orden de arranque implícito: la app B asume que la app A ya está lista cuando B arranca, sin verificarlo — funciona en desarrollo (donde arrancas todo a mano en el orden correcto) y falla aleatoriamente en producción.
Los seis comparten un patrón: alguien optimizó por conveniencia inmediata a costa de la independencia de despliegue. La ley del clúster que sigue es, en el fondo, la vacuna contra los seis a la vez.
La ley del clúster: toda arista es URL + clave, descubierta
La regla de oro que reemplaza a los seis acoplamientos anteriores es simple de enunciar: toda arista entre dos apps del clúster es una URL base pública más una clave de API de rol mínimo, y ambas se descubren consultando el registro — nunca se hardcodean. Esto significa que cualquier app puede moverse de host, escalar horizontalmente o redesplegarse sin que las demás se enteren de nada más que "la URL cambió, y el registro ya lo sabe". Ninguna app necesita saber qué contenedor, qué red interna o qué filesystem usa otra: solo necesita su URL pública y una clave con el privilegio mínimo que su tarea requiere (la lección 5 formaliza esos rangos de privilegio).
La heterogeneidad como virtud, no como problema
Un error común es pensar que un clúster "bien diseñado" debe ser tecnológicamente homogéneo: mismo lenguaje, misma base de datos, mismo framework en todas partes. El clúster de este curso demuestra lo contrario: conviven aplicaciones en Python y en Node.js, bases de datos PostgreSQL (para el volumen y la concurrencia de los gemelos digitales) y SQLite (para despliegues más simples y de menor escala), sin que eso rompa nada. Esto es posible precisamente porque la ley del clúster no depende de la tecnología interna de cada app — la arista es siempre HTTP + JSON + una clave, sin importar qué stack hay detrás. La heterogeneidad deja de ser un riesgo de integración y se convierte en libertad: cada equipo elige la herramienta correcta para su dominio, no la que "ya usan los demás".
Visualicemos las aristas principales del clúster:
Repasa el vocabulario central de esta lección:
1 de 5
El laboratorio de esta lección te deja explorar el grafo completo del clúster: siete nodos (el hub y las seis apps, más una séptima marcada como "tu app futura") dispuestos en órbita, con sus aristas reales — y un modo caos que apaga el hub para que compruebes con tus propios ojos que las conexiones establecidas sobreviven.
Laboratorio: Grafo del clúster: registro, aristas y modo caos
8. Custodia de datos: un backup no probado no es backup