Stack

Stack tecnológico

Cada fila es una elección concreta, no un default. La columna "dominio" es la misma paleta del diagrama de arquitectura — para ver de un vistazo qué corre en Python, qué es infraestructura pura y qué es Node.js.

Componente	Tecnología	Dominio
Feature store (offline)	`Feast + Postgres`	Infra
Feature store (online)	`Feast + Redis`	Infra
Catálogo de metadata de features	`Tabla feature_metadata en Postgres`	Infra
Entrenamiento y tracking	`Python + XGBoost + MLflow`	Python
Registro de modelos	`MLflow Model Registry`	Python
Formato de despliegue del modelo	`ONNX`	Python
API de inferencia	`Node.js / Fastify + onnxruntime-node`	Node.js
Métricas de servicio	`Prometheus (prom-client en Node)`	Monitoreo
Detección de drift	`Evidently (Python)`	Monitoreo
Dashboard de monitoreo	`Next.js + Recharts`	Node.js
Orquestación / infraestructura	`Docker + Docker Compose (servidor propio)`	Infra

Algunas elecciones, con su porqué

XGBoost sobre LightGBM

Decidido sin necesitar una comparación empírica — en un dataset de ~6,800 filas, ambos darían calidad similar. Dos motivos concretos: su export a ONNX es más maduro (necesario para servir desde Node.js), y su soporte nativo de categóricas evita tener que decidir un encoding manual.

ONNX como formato de despliegue

Permite que el modelo entrenado en Python se sirva desdeonnxruntime-node sin depender de un runtime de Python en producción. Validado con la comparación real: diferencia absoluta máxima de 8.58e-06 entre las predicciones del modelo original y el exportado — muy por debajo de la tolerancia elegida (1e-3).

Postgres consultado directo por cada servicio que lo necesita

Feast, la API de inferencia y el dashboard se conectan cada uno directo a Postgres para lo que necesitan — sin una capa de indirección extra. La API de inferencia no se convierte en un gateway general de datos; queda enfocada en su trabajo real: servir predicciones.