Una mirada técnica a la infraestructura que hace posible el proceso editorial descrito en Metodología: cómo se ingieren, filtran, sintetizan y publican las coberturas.
Un conjunto de workflows en n8n monitorea decenas de fuentes RSS y feeds de agencias de forma continua, dispara el procesamiento de cada historia nueva y coordina el resto del pipeline: deduplicación, síntesis, publicación y, para las coberturas urgentes, la difusión automática en redes.
Cuando entra una noticia nueva, primero se compara contra lo publicado en las últimas 48hs con una heurística barata (superposición de palabras y nombres propios). Los casos claros se resuelven ahí mismo sin costo de API. Para la franja ambigua del medio -dos títulos que podrían ser el mismo evento contado distinto, o dos eventos distintos que comparten vocabulario- se le pide a un modelo de lenguaje que arbitre puntualmente, en vez de forzar un único umbral numérico a separar casos que en la práctica se superponen.
Cuando varios medios cubren el mismo evento, el sistema no publica versiones redundantes: contrasta las distintas coberturas y sintetiza un único artículo, marcando explícitamente los puntos donde las fuentes discrepan en vez de elegir una versión de forma arbitraria.
Además del flujo editorial, el sitio expone un panel de herramientas de monitoreo e inteligencia de fuentes abiertas para seguimiento y análisis adicional más allá de los artículos publicados.
PostgreSQL con la extensión pgvector como base de datos principal, lo que habilita búsqueda semántica además de las consultas relacionales estándar (categoría, región, urgencia, fecha) que alimentan el resto del sitio.
Frontend en Next.js desplegado en Vercel; backend en Hono sobre Node.js, junto con n8n y Postgres, corriendo en Docker Compose sobre un VPS propio. Dos repos separados (frontend e infraestructura) para poder iterar y desplegar cada capa de forma independiente.
El sitemap se genera consultando el archivo completo de artículos, así que se reconstruye una sola vez por ventana de tiempo y se sirve cacheado el resto de los pedidos -incluyendo reintentos de rastreo de buscadores-, en vez de repetir el trabajo completo en cada visita. La primera versión de este cache vivía en memoria de proceso, lo cual no alcanza en un entorno con múltiples instancias corriendo en paralelo: se resolvió moviéndolo a un cache compartido a nivel de plataforma para que todas las instancias lean y escriban el mismo valor.
Quién construyó esto y por qué
Quién hace esto