Decisiones de arquitectura

Estas son las decisiones de diseño que dan forma a la plataforma. Cada una documenta un problema real, la opción elegida, por qué se descartaron las demás y qué se acepta a cambio. El objetivo es dejar constancia del criterio de ingeniería: no solo qué se usa, sino por qué.

El sistema está calibrado para un régimen de trabajo concreto (del orden de 1500 lecturas por segundo, unos 5 GB al día) con una arquitectura justificada para soportar diez veces esa carga sin reescrituras. Ese principio (construir para hoy, dejar el camino trazado para mañana) recorre casi todas las decisiones.

Nº	Decisión	Resumen
ADR-0001	Almacenamiento de series temporales: TimescaleDB	Una única base Postgres con extensión de series temporales en lugar de un motor columnar separado.
ADR-0002	Protocolo de ingesta: HTTP por lotes	Ingesta por HTTP con validación síncrona rica, más un puente MQTT opcional para clientes reales.
ADR-0003	Capa de streaming: Apache Kafka	Log durable particionado con fan-out a múltiples consumidores frente a colas o Redis Streams.
ADR-0004	Orquestación de flujos batch: Apache Airflow	Orquestador estándar de la industria para los trabajos programados, con UI, reintentos y backfill.
ADR-0005	Procesamiento de streams: Faust	Stream processing nativo en Python sobre Kafka, sin introducir una pila JVM.
ADR-0006	Detección de anomalías: Isolation Forest	Modelo no supervisado como principal, con un autoencoder como variante comparada por evidencia.
ADR-0007	Predicción de valores futuros: baseline → XGBoost → LSTM	Progresión de tres modelos comparados con validación temporal rigurosa.
ADR-0008	Seguimiento de experimentos y registro de modelos: MLflow	Plataforma MLOps autohospedada y open source para todo el ciclo de vida del modelo.
ADR-0009	Detección de deriva: Evidently AI	Monitorización de deriva de datos y de modelo en batch, open source, integrada con el registro.
ADR-0010	Arquitectura: multi-servicio por dominio	Un servicio por área técnica, ni monolito ni microservicios puros.
ADR-0011	Nube (fase 1): traslado directo a Kubernetes gestionado	Llevar el clúster entero a la nube sin tocar manifiestos ni código.
ADR-0012	Nube (fase 2): almacén analítico tipo lakehouse	Capa fría barata y consultable con el clúster apagado, separada de la operacional.
ADR-0013	Fuente de datos: gemelo digital del invernadero	Un simulador con estado, física y fallos frente a datos aleatorios sin sentido.
ADR-0014	Logs: backend de objeto para la agregación	Migrar el almacén de logs de disco local a almacenamiento de objetos duradero.
ADR-0015	Recogida de telemetría: agente unificado	Sustituir el recolector de logs deprecado por un agente único de logs, métricas y trazas.