Infraestructura de datos públicos: cómo escalar sin acumular deuda técnica invisible

Hay un momento en casi todos los proyectos de análisis de datos públicos en el que el equipo técnico se da cuenta de que el sistema que funciona bien a pequeña escala empieza a romperse. No de golpe. Poco a poco. Primero son latencias que nadie entiende. Luego son resultados que no concuerdan entre entornos. Después, una dependencia crítica que nadie documentó y que sostiene demasiadas piezas.

Ese momento no es un fallo de ejecución. Es el síntoma de una deuda técnica que se fue acumulando desde el diseño inicial, cuando nadie hizo las preguntas incómodas sobre cómo iba a crecer el sistema.

Escalar la infraestructura de análisis del universo público de Internet no es simplemente añadir capacidad. Es rediseñar las suposiciones sobre las que se construyó la capa de ingesta, procesamiento y entrega de datos derivados.

El error más frecuente: confundir volumen con complejidad

La mayoría de los equipos abordan la escalabilidad como un problema de volumen. Más fuentes, más almacenamiento, más ancho de banda. Pero el volumen es la parte más fácil de resolver. Lo que realmente escala mal es la complejidad estructural del dato.

Un flujo de procesamiento que maneja bien diez mil documentos diarios empieza a generar inconsistencias cuando maneja diez millones, no porque la infraestructura sea demasiado pequeña, sino porque las decisiones de normalización, deduplicación y clasificación que parecían triviales al principio generan fricción exponencial a escala.

El dato público no llega limpio. Llega con variaciones de formato, con estructuras inconsistentes según la fuente, con metadatos incompletos o directamente erróneos. Ignorar eso en la fase de diseño es la raíz de la mayor parte de la deuda técnica que aparece después.

Dónde se genera realmente la deuda técnica

Hay tres puntos concretos donde la deuda técnica se acumula de forma silenciosa en infraestructuras de datos públicos:

1. La capa de normalización sin esquema versionado. Si el esquema de normalización cambia sin control de versiones, los datos históricos y los datos nuevos se vuelven incomparables. Las series temporales pierden coherencia. Los análisis de tendencias se contaminan con artefactos del propio sistema, no del fenómeno que se analiza.

2. La ausencia de linaje del dato. Saber qué fuente generó un dato, cuándo fue procesado, con qué versión del pipeline y bajo qué reglas de filtrado es imprescindible para auditar resultados. Sin linaje, cada vez que un análisis devuelve un resultado inesperado, el equipo invierte horas reconstruyendo el origen del problema en lugar de resolverlo.

3. Los conectores de fuente escritos para un caso concreto. El conector que se desarrolló rápido para una fuente específica suele convertirse en un componente crítico no mantenible. Cuando esa fuente cambia su estructura —y todas las fuentes públicas cambian eventualmente— el coste de adaptación es desproporcionado porque el conector no se diseñó para ser modificable.

Lo que una infraestructura bien diseñada hace diferente

Una infraestructura de análisis de datos públicos que escala sin acumular deuda técnica comparte algunos rasgos que no son tecnológicos, sino arquitectónicos y de proceso.

El primero es la separación clara entre la capa de adquisición y la capa de análisis. Cuando ambas capas están acopladas, cualquier cambio en las fuentes requiere intervención en el análisis, y viceversa. Esa fricción se multiplica con el número de fuentes activas.

El segundo es el tratamiento del dato intermedio como producto. Los datos en tránsito —normalizados pero no aún analizados— deben tener contratos de calidad propios. Si nadie los valida antes de que lleguen a la capa analítica, los errores se amplifican sin que haya un punto de detección claro.

El tercero es la observabilidad. No como un añadido de monitorización genérica, sino como una capacidad integrada desde el diseño: saber en tiempo real cuántos documentos han pasado por cada etapa, cuántos han sido descartados y por qué, y dónde se están generando anomalías. Sin observabilidad, escalar es construir sobre ciego.

El marco regulatorio como guía de diseño

El Art. 4 de la Directiva (UE) 2019/790 sobre Text and Data Mining (TDM) establece que el procesamiento de datos públicos con fines analíticos tiene cobertura legal siempre que se respeten las condiciones de acceso a las fuentes y se limite a la extracción de análisis derivado. Eso tiene implicaciones directas en el diseño de la infraestructura.

Una arquitectura orientada al TDM no almacena contenido original de terceros como producto. Almacena análisis derivado: señales, tendencias, menciones estructuradas, metadatos enriquecidos. Eso no solo es una posición legal correcta —es también una decisión técnica que reduce el volumen de almacenamiento, simplifica la gobernanza del dato y clarifica qué se puede retener y durante cuánto tiempo.

En la práctica, los equipos que diseñan su infraestructura desde este principio tienen pipelines más limpios, contratos de datos más claros y menos conflictos entre lo que el sistema guarda y lo que legalmente puede guardar.

Cuándo es el momento de revisar la arquitectura

No hay una señal única. Hay un conjunto de síntomas que, cuando aparecen juntos, indican que la infraestructura ha llegado a su límite de escalabilidad orgánica:

• El tiempo de incorporación de una fuente nueva supera varias semanas y requiere intervención de múltiples perfiles técnicos.
• Los resultados de análisis varían dependiendo de cuándo se ejecuta la consulta, no de cuándo se generó el dato.
• El equipo no puede responder con certeza a la pregunta: ¿de dónde viene este dato y qué transformaciones ha sufrido?
• Añadir una nueva dimensión de análisis requiere modificar componentes que no deberían verse afectados.

Cuando esos síntomas son cotidianos, el coste de seguir operando sobre la arquitectura actual supera sistemáticamente el coste de revisarla.

En TrawlingWeb el procesamiento del universo público de Internet se construye sobre una infraestructura diseñada específicamente para sostener análisis derivado a escala, con linaje del dato, separación de capas y cobertura bajo el marco TDM del Art. 4 Directiva (UE) 2019/790. La escala no es el objetivo en sí misma. Es la consecuencia de haber resuelto bien los problemas de diseño desde el principio.

Si tu equipo está evaluando cómo estructurar o revisar su infraestructura de análisis de datos públicos, las preguntas que más importan no son las de capacidad. Son las de arquitectura.