Motor de recomendación de eventos culturales

El proyecto

Junto con un compañero, co-diseñé y construimos un producto de datos orientado a usuarios que querían descubrir eventos culturales (conciertos, exposiciones, teatro, cine) cerca de ellos, filtrados por sus intereses. Trabajamos de forma ampliamente autodirigida, definiendo conjuntamente las funcionalidades, las prioridades y las decisiones técnicas.

Lo que construí

Me responsabilicé de la arquitectura backend completa y de la mayor parte de la implementación:

• API principal con FastAPI: servía las búsquedas y recomendaciones de usuarios, con filtros por localización, categoría y fecha.
• Pipelines de ingesta y normalización: scrapers y conectores que recogían eventos de múltiples fuentes heterogéneas, los deduplicaban y los normalizaban a un esquema común antes de indexarlos.
• Apache Kafka para desacoplar la ingesta del procesamiento: los eventos llegaban de distintas fuentes a distintos ritmos, y Kafka absorbía esa variabilidad sin bloquear la API.
• Elasticsearch como motor de búsqueda e indexación: full-text search, búsqueda geoespacial y filtrado facetado para las consultas de usuarios.
• Motor de recomendación basado en reglas: asignación de eventos a perfiles de usuario según localización, categoría y preferencias anteriores.
• Stack completamente containerizado con Docker y Docker Compose: entornos de desarrollo reproducibles desde el primer día.

La arquitectura

Trabajar sin una base de código existente ni convenciones de equipo significa que todas las decisiones estructurales son tuyas. Elegí un monolito distribuido con separación clara de responsabilidades: ni microservicios puros, ni todo mezclado. La decisión correcta para ese momento. Mantenía el código navegable sin cerrar la puerta a extraer servicios si el producto escalaba.

El cliente archivó el proyecto antes de que llegara a los usuarios. El sistema funcionaba; la decisión no fue nuestra.