Deuda técnica en infraestructura de datos públicos: dónde se acumula y cuánto cuesta ignorarla

Hay organizaciones que llevan años trabajando con datos del universo público de Internet sin haber revisado una sola vez los cimientos sobre los que opera esa infraestructura. No porque no les importe. Sino porque mientras el sistema "funciona", no hay incentivo visible para cuestionarlo.

El problema es que la deuda técnica en infraestructura de datos no se anuncia. Se acumula en silencio: en parsers que nunca se actualizaron cuando cambiaron las fuentes, en esquemas de normalización que ya no reflejan la realidad del contenido que procesan, en flujos de ingestión que fueron diseñados para un volumen diez veces menor al actual. Cuando esa deuda vence, lo hace de golpe.

Este post no habla de teoría. Habla de dónde aparece esa deuda, por qué es difícil de detectar y qué decisiones concretas pueden evitar que se convierta en un problema estructural.

El error más común: confundir estabilidad con salud

Un sistema que no falla no es necesariamente un sistema sano. En infraestructura de datos públicos, la estabilidad aparente puede esconder patrones de degradación que solo se hacen visibles en momentos de estrés: un pico de volumen, un cambio en la estructura de una fuente relevante, una petición de análisis con una ventana temporal más amplia de lo habitual.

La deuda técnica en este contexto suele manifestarse en tres síntomas iniciales que pasan desapercibidos:

• Latencia progresiva sin causa aparente. El sistema procesa, pero cada semana tarda un poco más. Nadie lo documenta porque el umbral de alarma no se ha activado.
• Pérdida de cobertura silenciosa. Algunas fuentes dejan de procesarse correctamente tras un cambio estructural no detectado. El volumen total no cae lo suficiente como para activar alertas, pero el dato que falta es exactamente el que alguien necesitará en tres meses.
• Inconsistencias en la normalización. El mismo tipo de señal aparece representada de formas distintas según el momento en que fue procesada, porque el esquema ha evolucionado sin retrocompatibilidad.

Ninguno de estos síntomas detiene el sistema. Todos ellos erosionan la calidad del análisis derivado que produce.

Dónde se acumula la deuda con más frecuencia

En los adaptadores de fuente

El universo público de Internet no es estático. Las fuentes cambian sus estructuras, sus formatos, sus patrones de publicación. Un adaptador escrito para una fuente hace dieciocho meses puede estar procesando hoy un contenido estructuralmente diferente sin que nadie lo haya detectado. El resultado no es un error; es un dato incompleto o mal interpretado que pasa todos los filtros y llega al análisis con apariencia de correcto.

La revisión sistemática de adaptadores es una práctica que la mayoría de equipos aplaza indefinidamente. El coste de no hacerla no es inmediato, pero es acumulativo.

En los esquemas de normalización

Cuando un equipo empieza a trabajar con datos públicos, define un esquema de normalización que tiene sentido para su caso de uso inicial. Con el tiempo, ese esquema se estira: se añaden campos, se cambian definiciones, se incorporan fuentes con lógicas distintas. Si ese proceso no está gobernado, el resultado es un esquema que en papel es uno solo, pero en la práctica genera datos que no son comparables entre sí a lo largo del tiempo.

Esto es especialmente crítico cuando el análisis requiere series temporales. Un campo que significaba una cosa en enero y otra distinta en julio produce análisis que parecen correctos pero están comparando magnitudes distintas.

En la gestión de volumen

Muchas infraestructuras de datos públicos fueron dimensionadas para un volumen determinado y nunca se redimensionaron de forma proactiva. Se fue añadiendo capacidad de forma reactiva, en respuesta a incidentes, sin replantear la arquitectura de base. El resultado es un sistema que funciona, pero que tiene cuellos de botella estructurales que se activarán con el siguiente salto de volumen.

Por qué es difícil de detectar desde dentro

La deuda técnica en infraestructura de datos tiene una propiedad particular: quienes trabajan con ella a diario desarrollan tolerancia a sus síntomas. Se aprende a rodear los cuellos de botella. Se asume que ciertas inconsistencias son "normales". Se ajustan las expectativas al rendimiento degradado sin cuestionarlo.

Esto no es negligencia. Es el resultado natural de trabajar con sistemas complejos bajo presión operativa. Pero tiene una consecuencia directa: la deuda solo se hace completamente visible desde fuera, cuando alguien llega con una necesidad nueva que el sistema no puede cubrir con la calidad esperada.

En proyectos que implican Text and Data Mining (TDM) a escala, este momento suele coincidir con el arranque de un nuevo contrato, la incorporación de un nuevo caso de uso o la necesidad de ampliar la cobertura temporal del análisis. Es el peor momento posible para descubrir que la infraestructura no está en condiciones.

Qué decisiones concretas reducen la acumulación

No existe una solución única, pero hay prácticas que marcan diferencias medibles:

Auditorías de cobertura periódicas. No de rendimiento, sino de cobertura real. Qué porcentaje de las fuentes definidas como críticas está siendo procesado correctamente, con qué latencia y con qué tasa de completitud de campos.

Versionado explícito de esquemas. Cada modificación en el esquema de normalización debe ser trazable, con fecha y motivo. Los datos procesados antes de un cambio deben estar etiquetados con la versión del esquema que se les aplicó.

Tests de regresión sobre fuentes críticas. Cuando una fuente cambia su estructura, el fallo debe ser detectable antes de que afecte al análisis. Esto requiere tests automáticos que validen no solo que el sistema procesa, sino que lo que procesa es coherente con lo esperado.

Revisiones de capacidad desacopladas de los incidentes. El dimensionamiento no debería revisarse solo cuando hay un problema. Debería tener un ciclo propio, vinculado a las proyecciones de volumen y a la incorporación de nuevas fuentes.

En TrawlingWeb, la infraestructura sobre la que operan los servicios de análisis del universo público ha sido diseñada con estos principios como base operativa, no como aspiraciones. La razón es práctica: a la escala a la que opera el procesamiento de datos públicos, la deuda técnica no perdonada tiene un coste directo en la calidad del análisis derivado que llega al cliente.

La deuda que no se gestiona, se hereda

Cada equipo que trabaja con datos del universo público de Internet tiene, en algún momento, que decidir si gestiona su deuda técnica de forma deliberada o si la deja acumularse hasta que alguien la herede. Esa herencia suele llegar en el peor momento: cuando hay más presión, más volumen y menos margen para refactorizar.

La infraestructura de datos no es un activo pasivo. Es un sistema vivo que requiere revisión continua. Tratarla como algo que "ya funciona" es la decisión que convierte deuda manejable en coste estructural.

Si tu infraestructura actual no puede responder a esas preguntas con datos concretos, ya tienes el diagnóstico. El siguiente paso es decidir cuándo empezar a resolverlo.