ADR 0001 — n8n no es el núcleo

Estado: aceptado Fecha: 2026-09

Contexto

El planteamiento inicial fue construir todo el sistema como un flujo de n8n. Al crecer el alcance a tres carriles, diffing de entidades y scoring, el diseño dejó de encajar.

Problema

No es que el sistema sea grande. Es que tres de sus piezas son código de dominio disfrazado de plomería, y n8n no sabe tratarlas como código:

Normalizadores por fuente. Un normalizador es una función pura y su único modo de fallo real es que la fuente cambie un campo sin avisar. Eso se detecta con un test contra un payload congelado. En n8n vive dentro de un nodo Code, sin test, sin pull request, y el export JSON del workflow es ilegible en un diff. Cuando el Banco Mundial cambie notice_text, nos enteramos porque el reporte salió vacío tres semanas.

Diff de entidades del carril B. Requiere comparar snapshots versionados y decidir qué constituye un cambio reportable. Es lógica de dominio, no plomería.

Scoring. Reglas con pesos que se calibran, más llamadas a LLM con caché versionado por prompt.

Reprocesamiento. "Volvé a correr el normalizador sobre los 8.000 registros que ya ingerí" es una operación que se va a necesitar cada vez que se mejore una regla. En n8n es un dolor.

Interfaz de operador. La tabla de decisiones necesita que un humano la toque. n8n no da nada para eso.

Decisión

El núcleo es Python + Django + Postgres, monolito, un solo servidor.

n8n no desaparece: se degrada a la última milla. Entrega a Slack, correo, Telegram, y cualquier pegamento que alguien no desarrollador deba poder cambiar sin tocar el repo. Eso es exactamente para lo que sirve.

Criterios usados

1. Quién mantiene esto dentro de ocho meses
2. Testabilidad de los normalizadores, que es donde se rompe
3. Costo de reprocesar histórico
4. Costo operativo proporcional a 12–16 ofertas al año, no a un producto SaaS
5. Camino a UI de operador sin abrir un proyecto aparte

Django gana el criterio 1 por experiencia previa del equipo, antes que por cualquier mérito técnico. El stack que uno puede depurar un martes a las once de la noche vence al óptimo teórico.

Django gana el criterio 5 por el admin: la tabla de decisiones, el registro de fuentes y la revisión de ítems obtienen interfaz gratis. Eso elimina un frontend entero de las fases 1 a 4.

Consecuencias

• Hay que mantener un servidor, cosa que n8n cloud evitaba
• Se necesita disciplina de tests que n8n no exigía
• A cambio: pull requests legibles, reprocesamiento trivial, admin gratis

Alternativas descartadas

Todo en n8n. Descartada por lo anterior.

Airflow / Prefect. Peso operativo desproporcionado para cientos de registros diarios.

Dagster. Defendible por su modelo de activos y su backfill. Descartada por ahora: es un segundo sistema que aprender y operar para un problema que aún no tenemos. Revisar si pasamos de unas 40 fuentes o si el backfill se vuelve semanal.