La arista de dependencia que te miente

Pedile a un equipo de plataforma su diagrama de arquitectura y vas a recibir una de dos cosas: una página de Confluence con un sello de "última edición hace 14 meses", o un encogimiento de hombros y un hilo de Slack donde tres personas discuten si el servicio de pagos todavía llama a inventory directamente o si pasó por el event bus en la migración del Q3 que nadie terminó de documentar. Ambas respuestas son correctas, en el sentido de que ambas son lo que realmente pasa en la mayoría de los equipos a partir de cierto tamaño.

El diagrama no está mal porque alguien fue vago. Está mal porque un diagrama es una afirmación sobre el sistema congelada en el momento en que alguien lo dibujó, y el sistema siguió avanzando. Cada dependencia que no sacaste, cada llamada nueva que alguien agregó bajo presión de un deadline con la intención de limpiarla después, cada camino de fallback que solo se dispara en producción — nada de eso aparece en un diagrama de cajas y flechas a menos que alguien vuelva y lo redibuje. Nadie lo redibuja. Esa brecha entre el sistema tal como está documentado y el sistema tal como corre es lo que llamamos drift arquitectónico, y no es una hipótesis: es el estado por defecto de cualquier sistema lo suficientemente viejo como para que lo haya tocado más de un ingeniero.

Dos fuentes de verdad, y ninguna alcanza sola

El análisis estático lee lo que escribiste: parseá el código fuente, resolvé los imports, seguí los clientes HTTP y los listeners de Kafka, y obtenés un grafo de lo que el código dice que debería estar llamando a qué. Es preciso y barato de calcular, pero solo conoce los caminos que existen en el fuente — un feature flag que está al 100% desde hace ocho meses y nunca tuvo su rama vieja borrada igual se ve "usado" para una lectura puramente estática, y una llamada que solo ocurre por reflexión o una URL construida dinámicamente puede no aparecer para nada.

La observación en runtime es el espejo opuesto. Mirá el tráfico real — qué puerto le habló a qué contenedor, con qué frecuencia, qué tan rápido — y obtenés exactamente lo que está pasando ahora mismo, sin necesidad de interpretación. Pero los datos de runtime no tienen memoria de la intención. No pueden decirte si una llamada fue diseñada a propósito o es un resto que a nadie le toca sacar, y si la muestra de tráfico se pierde un batch job nocturno que corre una vez al día, esa dependencia le es invisible.

Ninguna de las dos miente, exactamente. Las dos dicen la verdad sobre una pregunta distinta.

Lo que realmente te compra etiquetar cada arista

La movida útil no es elegir una fuente sobre la otra — es quedarte con las dos y negarte a fusionarlas en un único hecho sin etiquetar. Cada arista de dependencia en el grafo de Archynt lleva de dónde salió: static (encontrada en el código fuente, nunca observada en vivo), runtime (observada en tráfico, no escrita en ningún lado), o both. Ese tercer estado, confirmed_by: both, es el único sobre el que podés actuar con confianza real — significa que el código y el cable están de acuerdo.

Los otros dos son donde viven los hallazgos interesantes. Una arista solo static sin tráfico de runtime en semanas es una candidata a código muerto — una dependencia que probablemente puedas borrar, y ahora tenés evidencia en vez de una suposición. Una arista solo runtime es lo opuesto y, en nuestra experiencia, la más urgente: una dependencia viva que nadie anotó, lo que significa que nadie es dueño de ella, nadie tiene alertas sobre ella, y la próxima persona que toque el servicio que hace la llamada no tiene idea de que es crítica hasta que la rompe.

Por qué esto es una conversación de riesgo, no de documentación

Es tentador archivar el drift bajo "mantener la documentación al día", que es exactamente por qué la mayoría de los equipos nunca lo arregla — la deuda de documentación pierde toda reunión de priorización contra cualquier cosa con un ticket y un deadline. El planteo más honesto es que una dependencia de runtime sin dueño es superficie de ataque sin monitorear y un punto único de falla no planeado al mismo tiempo. Nadie está de guardia por una conexión de cuya existencia no sabe. Ese es el argumento con el que arrancamos ahora, porque es el que sobrevive el contacto con una reunión de roadmap.