Escalando de forma asíncrona acciones relevantes de usuarios

Hasta hace poco en la sección de estadísticas para usuarios profesionales nos veíamos limitados a mostrar los datos del último año debido al gran volumen de información existente en nuestros sistemas de persistencia.

Para solucionar esta limitación decidimos elegir elasticsearch como motor de búsqueda. además de resolver este problema pudiendo filtrar datos estadísticos por más de un año, también tuvimos la oportunidad de poder mostrar información más relevante a nuestros clientes. Esta información ayuda a un cliente a entender la evolución de las visitas a sus inmuebles, así como el número de contactos.

Nos vimos, por tanto, en la situación de trazar los eventos más destacados que puede realizar un usuario con respecto a los inmuebles que gestiona. Acciones como incluir una foto en un anuncio, bajar el precio de un inmueble tomaban una relevancia aún mayor para nuestros clientes, etc..

Tras realizar unas cuantas estimaciones nos dimos cuenta de que era inviable, en términos de velocidad de respuesta y escalabilidad, almacenar toda esta información en un esquema de tablas de una base de datos convencional.  Esto perjudicaría enormemente el rendimiento de la misma, así como la experiencia de usuario de nuestros clientes al realizar cualquier acción que quisiésemos monitorizar.

Utilizando elasticsearch como motor de búsqueda el problema de la escalabilidad lo tendríamos resuelto por la facilidad que ofrece esta herramienta para escalar horizontalmente. Sin embargo, para que no empeorase la experiencia de usuario tendríamos que pensar una solución que no afectase significativamente al rendimiento y que estuviese bastante cerca del tiempo real. En este punto decidimos que lo que necesitábamos era tratar los eventos de manera asíncrona.

Nuestra solución

Nuestra idea para solventar el problema se fundamenta en el uso de colas de mensajes utilizando el modelo punto a punto en el cual un cliente envía un mensaje y otro lo recibe. De tal manera que si desde un cliente pudiésemos producir un mensaje y delegar la responsabilidad de procesarlo y almacenarlo en otro cliente podríamos resolver el problema.

La tecnología empleada para llevarlo a cabo es la api jms junto con apache activemq para la persistencia del propio jms, además del ya mencionado elasticsearch

Así pues, la API interna generará un mensaje que, según nuestra arquitectura orientada a la robustez y consistencia de datos, se almacenará en un broker local de activemq hasta que sea enviado por un proceso independiente a nuestro servidor centralizado de activemq. Escuchando los mensajes que lleguen a esta cola tendremos un proceso que será el encargado de realizar la agregación. Una vez agregados los datos pasan a ser almacenados en unos registros de históricos e indexado en los índices de elasticsearch, para posteriormente mostrarlos en forma de eventos sobre una gráfica como puede verse en el siguiente gráfico.

Podemos observar como nuestro cliente dió visibilidad a la calle dónde se encontraba el inmueble además de adjuntar unas cuantas fotos. estas dos acciones, tal y como se puede ver en la gráfica, repercuten positivamente para los intereses de nuestro cliente aumentando casi un 300% el número de impactos recibidos en ese inmueble

Algunos datos y conclusiones
Actualmente se registran cerca de 100.000 eventos diarios. Gracias a la asincronía en el proceso, a la modularización por responsabilidades de los distintas tecnologías y a la escalabilidad horizontal que nos proporciona el motor de búsqueda somos capaces de procesar y mostrar los datos en un tiempo cercano al real.