En el panorama actual del comercio digital, ofrecer recomendaciones personalizadas y relevantes en tiempo real se ha convertido en un factor diferencial para la retención y satisfacción de los usuarios. Sin embargo, construir un sistema de recomendación capaz de procesar millones de solicitudes por segundo, mantener la frescura de los datos y controlar los costes de infraestructura supone un desafío tanto de orquestación como de machine learning. En Q2BSTUDIO, como empresa especializada en desarrollo de software a medida y soluciones cloud, hemos diseñado e implementado arquitecturas que combinan procesamiento batch con capacidades en tiempo real, aprovechando el ecosistema de AWS para ofrecer experiencias personalizadas a gran escala.
Este artículo explora cómo construir un sistema de recomendación escalable siguiendo un enfoque 'batch-first' (primero por lotes) y extendiéndolo progresivamente con componentes en tiempo real. La arquitectura se apoya en servicios como AWS Lake Formation, Amazon Managed Workflows for Apache Airflow (MWAA), Amazon Athena, AWS Glue, Amazon SageMaker, Amazon DynamoDB y Amazon MemoryDB, todos ellos orquestados para lograr un equilibrio entre eficiencia operativa y latencia mínima. Además, se aborda cómo integrar señales de inteligencia artificial y agentes IA para enriquecer el perfil del usuario sin disparar los costes.
Fundamentos de una arquitectura batch-firstLa mayoría de los sistemas de recomendación comienzan con un pipeline por lotes que procesa datos históricos —catálogos, transacciones, embeddings— y genera listas de candidatos que se almacenan en una base de datos de baja latencia. Este enfoque es fiable, económico y fácil de depurar. En nuestra experiencia, el primer paso es construir un data lake centralizado que sirva como única fuente de verdad. Con AWS Lake Formation y Amazon S3, creamos conjuntos de datos 'golden' (depurados y validados) accesibles de forma segura desde múltiples cuentas de AWS. Esto elimina la duplicación de datos y garantiza que todos los pipelines (formación de modelos, inferencia batch, dashboards de BI) trabajen sobre la misma información.
La orquestación recae en Amazon MWAA, que gestiona flujos de trabajo complejos definidos en código Python. Cada pipeline sigue un patrón consistente: extracción de datos mediante Amazon Athena, transformaciones intensivas con AWS Glue (PySpark), formación de modelos y vector search con Amazon SageMaker, y publicación de resultados en DynamoDB. Para acelerar el desarrollo, creamos operadores personalizados reutilizables que encapsulan lógica común (gestión de roles IAM, escritura en rutas S3 por convención, reintentos automáticos). En Q2BSTUDIO aplicamos esta misma filosofía al desarrollar aplicaciones a medida: invierte en componentes reutilizables para que los equipos puedan lanzar nuevas funcionalidades en días, no semanas.
Un aspecto clave es el aislamiento por mercado. Cada marketplace se ejecuta en su propio grupo de tareas dentro del DAG, de modo que un fallo en uno no afecta a los demás. Además, los pipelines se ejecutan secuencialmente para evitar contención de recursos en trabajos pesados de SageMaker y Glue. Todo el intercambio de datos entre pasos se realiza mediante rutas S3 implícitas, sin necesidad de direcciones codificadas.
De batch a tiempo real: cuando la frescura importaEl modelo batch cubre la mayoría de los casos de uso (recomendaciones basadas en historial de compras, relaciones de catálogo), pero hay situaciones donde la información cambia en segundos: búsquedas recientes, añadidos al carrito, actividad en sesión. Para estos escenarios, extendimos el sistema con Amazon MemoryDB (compatible con Valkey) para búsqueda vectorial en tiempo real y endpoints de SageMaker para generación de embeddings bajo demanda. El mismo pipeline batch que publica en DynamoDB también actualiza semanalmente el índice de productos en MemoryDB. En tiempo de servicio, cuando un usuario realiza una acción reciente, el sistema genera un embedding en el momento, consulta los vecinos más cercanos en MemoryDB (con latencia sub-milisegundo) y combina esos resultados con los candidatos batch mediante un re-ranking en la capa de presentación.
Esta arquitectura híbrida permite mantener la eficiencia del procesamiento por lotes para señales lentas —como preferencias históricas— y la agilidad del tiempo real para señales rápidas —como la sesión actual—. Todo ello compartiendo los mismos modelos, el mismo data lake y el mismo servicio de presentación. En Q2BSTUDIO ayudamos a nuestros clientes a diseñar este tipo de transiciones graduales, evitando la tentación de construir un sistema completamente en tiempo real desde el inicio. Como hemos aprendido, 'batch first, real-time later' es una estrategia que reduce riesgos y costes.
Además, la integración de agentes IA permite personalizar aún más los resultados. Por ejemplo, un agente puede analizar el contexto de la sesión y aplicar reglas dinámicas de negocio antes de devolver la recomendación final. Estos agentes se despliegan como funciones serverless o endpoints de SageMaker, y se orquestan dentro del mismo flujo de Airflow o desde el servicio de presentación.
Seguridad, fiabilidad y lecciones aprendidasLa seguridad es transversal. Con Lake Formation controlamos el acceso a nivel de tabla entre cuentas, cada motor de cómputo (MWAA, Glue, SageMaker) usa roles IAM con mínimos privilegios, y los entornos se despliegan en VPCs aisladas por región. La fiabilidad se apoya en el aislamiento regional: cada región ejecuta su propia copia independiente del sistema, de modo que un fallo en una no afecta a las demás. Si un pipeline batch falla a mitad de ejecución, los datos de DynamoDB de la ejecución anterior siguen sirviendo hasta la siguiente actualización. Los reintentos automáticos de Airflow y la expiración TTL de DynamoDB garantizan que los datos obsoletos no persistan indefinidamente.
Entre las lecciones aprendidas destacamos:
Separar cómputo y almacenamiento: Usar S3 como capa intermedia y trabajos efímeros de Glue/SageMaker permite pagar solo por el cómputo activo, sin clústeres ociosos entre ejecuciones semanales.
Invertir en un data lake gobernado: Los conjuntos golden aceleran la incorporación de nuevos pipelines y hacen que las comparaciones entre modelos sean fiables. La inversión inicial en Lake Formation se amortiza rápidamente.
No todas las señales necesitan tiempo real: Clasificar las señales por velocidad de cambio y rutarlas adecuadamente (batch para las lentas, tiempo real para las rápidas, re-ranking para las intermedias) optimiza costes y rendimiento.
En Q2BSTUDIO aplicamos estos principios en cada proyecto de transformación digital. Ya sea desarrollando software a medida con componentes cloud, integrando inteligencia artificial o implantando soluciones de ciberseguridad, nuestro objetivo es ofrecer sistemas escalables, seguros y adaptados a las necesidades reales del negocio. Si deseas explorar cómo implementar un sistema de recomendación personalizado en tu organización, te invitamos a conocer nuestros servicios en desarrollo de aplicaciones a medida y en cloud AWS/Azure.
En resumen, construir un sistema de recomendación escalable en AWS no es solo cuestión de elegir los servicios adecuados, sino de orquestarlos siguiendo un enfoque iterativo que priorice la eficiencia batch antes de añadir complejidad en tiempo real. La combinación de Amazon MWAA, Lake Formation, SageMaker, DynamoDB y MemoryDB, junto con agentes IA y un data lake gobernado, proporciona una base sólida para ofrecer experiencias personalizadas a millones de usuarios sin disparar los costes. Como siempre, el mejor sistema es aquel que evoluciona con el negocio.




