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».
A lo largo de este curso hemos recorrido, en orden, cada capa del estándar de ingeniería que hace posible que seis aplicaciones heterogéneas — distintos lenguajes, distintas bases de datos, distintos equipos — operen como un solo sistema coherente sin estar acopladas entre sí. El registro (lección 1) resuelve el descubrimiento sin convertir al hub en un intermediario ni en un punto único de fallo. Los contratos JSON Schema (lección 2) son la frontera formal y verificable entre productores y consumidores, versionados explícitamente. El bus de eventos sin broker (lección 3) ofrece dos modos de consumo de primera clase — webhook firmado y polling con cursor — sin la complejidad operativa de un broker dedicado. La entrega imperfecta (lección 4) se domina con idempotencia, backoff determinista y dead-letter, aceptando que at-least-once es la realidad honesta. La seguridad máquina-a-máquina (lección 5) descansa en claves con rango de privilegio mínimo, hashes en vez de secretos en claro, y decisiones explícitas de fail-open/fail-closed por operación. La observabilidad científica (lección 6) mide el clúster en el tiempo con percentiles e histéresis, no solo con un estado binario del instante actual. La procedencia formal (lección 7) hace que cada dato científico resista a un revisor externo, con hashes verificables y honestidad sobre los huecos. Y la custodia de datos (lección 8) exige que cada backup se pruebe de verdad, con RPO y RTO explícitos, y con la regla de oro de que las grabaciones crudas nunca salen de su host.
El proyecto: presentación
El proyecto final de este curso te pide aplicar el estándar completo a un caso concreto: integrar una nueva aplicación al clúster de seis. No se trata de escribir código de esa aplicación (no existe todavía) — se trata de diseñar la integración con el mismo nivel de rigor que exigiríamos a cualquiera de las seis apps reales que ya operan en producción: su contrato, su modelo de seguridad, qué reporta a observabilidad, y cómo custodia sus propios datos.
El formato ADR como entregable profesional
La pieza central de tu entrega es un ADR (Architecture Decision Record), el formato con el que documentamos cada decisión de arquitectura seria en este clúster: contexto (qué problema hay que resolver y qué restricciones existen), decisión (qué se decidió hacer, de forma concreta y verificable), alternativas descartadas (qué otras opciones se consideraron y por qué se rechazaron — un ADR sin alternativas descartadas es solo una afirmación, no una decisión razonada) y consecuencias (qué implica esta decisión a futuro, incluyendo sus costos y sus limitaciones honestas, no solo sus ventajas). Un ADR no es un documento que se escribe una vez y se archiva: es la memoria institucional que le explica a quien llegue después por qué el sistema es como es, no solo qué es.
El lema de la casa: honestidad documental
Si este curso deja una sola idea grabada, que sea esta: la ingeniería de sistemas distribuidos seria no consiste en afirmar que todo funciona perfectamente — consiste en separar con precisión lo que es verificable hoy de lo que es una ventana de oportunidad futura. Un ADR que dice "esto está verificado end-to-end" cuando en realidad no lo está es peor que uno que dice honestamente "esto no se ha probado bajo carga real; es la próxima ventana de trabajo". La lección 7 lo llamó "procedencia teatral" en el contexto de datos científicos; aquí es exactamente la misma disciplina aplicada al diseño: nombra tus huecos, no los escondas.
Repasa todo el curso con este cuestionario general:
Un ADR que documenta la integración de una nueva app afirma "el modelo de seguridad está completamente verificado" sin haber probado nunca el flujo de rotación de claves. ¿Qué principio de este curso viola esa afirmación?
8. Custodia de datos: un backup no probado no es backup