Repliqué, de punta a punta, el sistema que la NASA usa para recibir y procesar las fotos y los datos ambientales del rover Perseverance en Marte. No es un notebook de ejemplo: es un pipeline de datos real, con el protocolo espacial auténtico, corriendo con datos generados en vivo.

El problema

Cada vez que el rover Perseverance toma una foto o mide la temperatura en Marte, esos datos viajan empaquetados en un protocolo espacial real (CCSDS), cruzan entre 3 y 22 minutos de espacio hasta la Tierra, y recién ahí un equipo de ingeniería los recibe, valida, calibra y convierte en algo que un científico puede usar. Quise construir ese sistema completo — no una simulación de juguete, sino la misma arquitectura que usaría un equipo de datos profesional para resolver este problema.

Sistema de información – Arquitectura

Qué construí

• El protocolo real, no uno inventado — un simulador que empaqueta imágenes y telemetría exactamente como especifica el estándar CCSDS 133.0-B-2, con checksum CRC-16 incluido.
• Arquitectura Medallion completa — los datos pasan por capas Raw → Bronze → Silver → Gold, cada una con su responsabilidad: nada se valida dos veces, nada se salta un paso.
• Detección de anomalías automática — el sistema revisa solo cada lectura de temperatura, presión y viento, y marca lo que se sale de rango, sin que nadie tenga que mirar una tabla a mano.
• Todo versionado como código — no solo el pipeline: el dashboard de monitoreo y la infraestructura en la nube también viven en el repositorio, no se armaron a mano en una interfaz y listo.
• Infraestructura híbrida — corre local con Docker, y tiene la variante en AWS (Terraform) lista para desplegar según el costo real de cada servicio.
  
  

AWS – architecture diagram

La prueba

El dashboard no muestra datos de ejemplo: la curva de temperatura que ves ahí reproduce la forma real del modelo físico de Marte (mínimo antes del amanecer, máximo después del mediodía marciano), generada por el propio simulador y procesada por el pipeline completo hasta llegar a pantalla.

Orquestación con Airflow

Una historia real: cómo casi pierdo el dashboard (y por qué no lo vuelvo a perder)

Armé el dashboard de monitoreo directo en la interfaz de Grafana — parecía terminado. Al día siguiente, los paneles habían desaparecido: solo quedaba el título. La causa real: nada de la configuración de Grafana estaba guardada como código, así que todo vivía únicamente en un volumen interno que cualquier reinicio podía borrar sin aviso. La solución no fue rehacer los paneles a mano otra vez — fue tratar el dashboard como se trata cualquier otra parte del sistema: escribirlo como archivos versionados (datasource.yml, el JSON del dashboard) que se reconstruyen solos cada vez que el servicio arranca. Ahora un reinicio, una migración de máquina, o perder el disco no vuelve a borrar meses de trabajo de configuración.

Metodología: Spec-Driven Development

Todo el proyecto se construyó bajo una metodología de desarrollo dirigido por especificaciones: cada funcionalidad se especifica, se planea y se prueba antes de implementarse, bajo una constitución de 8 principios no negociables (fidelidad al dominio real, arquitectura Medallion sin atajos, verificación real con tests automáticos, cero secretos escritos a mano, entre otros). Es la forma en la que estoy aprendiendo a trabajar con agentes de IA en proyectos reales: el agente acelera la escritura del código, pero el entendimiento, las decisiones de arquitectura y la validación siguen siendo míos.

Stack técnico

Python · Apache Kafka · Apache Airflow · dbt · PostgreSQL/PostGIS · Docker · Terraform · AWS · Grafana · GitHub Actions

Ver el repositorio completo en GitHub