Infraestructura de datos públicos: cuando escalar rompe los supuestos del diseño original

Hay un momento concreto en la vida de cualquier infraestructura de datos en el que la arquitectura deja de comportarse como se esperaba. No es un fallo técnico en sentido estricto. Es algo más difícil de diagnosticar: los supuestos sobre los que se construyó el sistema ya no corresponden a la realidad que ese sistema tiene que procesar.

Ese momento casi nunca aparece con una alerta clara. Aparece como una acumulación de síntomas dispersos: colas que crecen sin razón aparente, latencias que se estabilizan en umbrales incómodos, inconsistencias en el volumen de señales procesadas que nadie sabe explicar del todo. Y cuando el equipo empieza a investigar, la respuesta suele ser la misma: el sistema funciona, pero ya no funciona para lo que necesitamos que haga.

Entender por qué ocurre esto —y cómo anticiparlo— es más valioso que cualquier receta de arquitectura. Porque el problema no es técnico en el sentido de que haya código roto. El problema es estratégico.

Los supuestos que nadie escribe pero todos asumen

Cuando se diseña una infraestructura de datos públicos, se toman decisiones implícitas que rara vez quedan documentadas. Cuántas fuentes se van a procesar simultáneamente. Qué variabilidad tendrá el volumen de señales por franja horaria. Qué nivel de heterogeneidad estructural tendrán los datos de entrada. Cuánto tiempo puede permitirse el sistema entre que una señal aparece en el universo público y que está disponible para el análisis.

Esos supuestos son razonables cuando el sistema es nuevo y el alcance está definido. El problema llega cuando el alcance cambia —porque el negocio crece, porque se incorporan nuevas fuentes, porque el tipo de análisis evoluciona— y nadie ha revisado si los supuestos originales siguen siendo válidos.

Un ejemplo habitual: un sistema diseñado para procesar un volumen estable de fuentes estructuradas empieza a incorporar fuentes semiestructuradas con frecuencias de actualización irregulares. El pipeline no falla. Pero el tiempo de procesamiento se dispara en franjas concretas porque la lógica de priorización no contemplaba esa variabilidad. El síntoma es latencia. La causa es un supuesto de diseño obsoleto.

Escalar no es añadir recursos, es revisar la lógica

La respuesta instintiva ante una infraestructura que no rinde es añadir capacidad: más nodos, más memoria, más paralelismo. A veces funciona. Pero cuando el problema es de diseño y no de recursos, añadir capacidad solo aplaza el diagnóstico real y lo encarece.

Escalar bien implica antes que nada entender dónde está el cuello de botella real. Y en infraestructuras de datos públicos, ese cuello suele estar en lugares inesperados:

• La capa de normalización: cuando el volumen de formatos distintos supera lo que el sistema fue diseñado para manejar, la normalización se convierte en el punto más lento del pipeline aunque nadie la haya identificado como crítica.
• La lógica de deduplicación: a medida que crece el universo de fuentes, la probabilidad de que la misma señal aparezca en múltiples puntos aumenta. Si la deduplicación no escala en paralelo con el volumen, introduce ruido en el análisis sin que sea evidente en las métricas de rendimiento.
• La gestión de prioridades: no todas las señales del universo público tienen el mismo valor temporal. Un sistema que las trata con la misma urgencia independientemente de su origen o tipo está malasignando recursos de forma sistemática.

Identificar cuál de estos puntos está fallando requiere instrumentación específica, no solo métricas agregadas de rendimiento. Y requiere equipos que entiendan tanto la lógica del negocio como la arquitectura técnica.

Heterogeneidad del universo público: el factor que más subestiman los diseños iniciales

El universo público de Internet no es homogéneo. Nunca lo ha sido. Pero la velocidad a la que esa heterogeneidad crece —en formatos, en idiomas, en estructuras, en frecuencias de actualización— supera sistemáticamente las previsiones de diseño.

Una infraestructura que en su primer año procesaba fuentes con tres o cuatro patrones estructurales distintos puede estar manejando veinte en su tercer año de operación. Si la lógica de procesamiento no ha evolucionado al mismo ritmo, el sistema empieza a comportarse de forma opaca: procesa, pero no se sabe bien qué está procesando ni con qué nivel de fiabilidad.

Este es uno de los problemas más costosos porque sus efectos son silenciosos. El pipeline no falla. Los datos llegan. Pero la calidad analítica del output se degrada de forma gradual y casi imperceptible hasta que alguien en el equipo de análisis señala que los resultados no cuadran.

En infraestructuras orientadas al Text and Data Mining, este problema tiene consecuencias directas sobre la validez del análisis derivado. Si los datos de entrada llevan heterogeneidad no gestionada, el modelo que opera sobre ellos incorpora esa heterogeneidad como ruido. No como señal.

Cuándo rediseñar y cuándo parchear

No siempre la solución es un rediseño completo. Pero tampoco siempre un parche es suficiente. La pregunta correcta no es "¿qué está fallando?" sino "¿cuánto le queda de vida útil al diseño actual con los requisitos actuales?"

Algunos indicadores que sugieren que los parches ya no son la respuesta:

• El tiempo de procesamiento de extremo a extremo ha crecido más del doble en los últimos doce meses sin que el volumen de fuentes haya crecido en la misma proporción.
• La deuda técnica acumulada en la capa de normalización requiere intervención manual recurrente para mantener la fiabilidad del output.
• El equipo técnico dedica más tiempo a mitigar síntomas que a desarrollar nuevas capacidades.
• Los supuestos de diseño originales ya no son reconocibles en el sistema actual porque han sido parcheados hasta hacer irreconocible la lógica inicial.

En ese punto, insistir en parches tiene un coste de oportunidad real: cada semana que el equipo dedica a mantener una arquitectura obsoleta es una semana que no se invierte en infraestructura que pueda soportar los siguientes tres años de crecimiento.

La pregunta que conviene hacerse antes de que el sistema lo decida por ti

Las infraestructuras de datos públicos no colapsan de golpe. Se degradan despacio, y en esa degradación gradual se pierde algo más difícil de recuperar que el rendimiento técnico: la confianza en los datos que produce el sistema.

Un equipo de análisis que duda de si los datos que está viendo son fiables o son un artefacto del pipeline no puede hacer su trabajo. Y esa duda, una vez instalada, es muy difícil de eliminar aunque se resuelva el problema técnico subyacente.

La pregunta que conviene hacerse con regularidad —al menos una vez al año, o cada vez que el alcance de la infraestructura cambia de forma significativa— es simple: ¿los supuestos sobre los que construimos este sistema siguen siendo válidos para lo que necesitamos hacer con él ahora?

En TrawlingWeb, esa revisión no es un evento puntual. Es parte de la lógica operativa de una infraestructura que tiene que mantenerse alineada con un universo público que cambia constantemente. No porque el cambio sea la meta, sino porque la fiabilidad del análisis derivado depende de ello.