Haremos un diseño de arquitectura tomando como ejemplo un cine de color azul

Unos meses atrás, comencé a ir al cine nuevamente (considerando las precauciones que con esto conlleva), y durante mi experiencia, quise utilizar la aplicación y el sitio web de un cine muy grande de México. Sin embargo, la experiencia me resultó desastrosa desde mi perspectiva de cliente final, por lo que hoy, trataremos de diseñar una arquitectura que sirva como base para escalar un negocio similar

Aclaración: no tengo información sobre el tráfico que tienen en su sistema o de los retos específicos que podrían estar enfrentando. Por lo que para cada ángulo que tengamos, habrá que justificar la existencia de los componentes propuestos

También, es muy importante mencionar que no hay una solución infalible. Cada problema es totalmente distinto, y es posible que, la suma de tecnologías, librerias y frameworks no actualizados, mal manejo de proyecto o prioridades, o necesidad de integración con sistemas legados podrían llevar a una mala experiencia de usuario

Problemas

Búsquedas

Las búsquedas son muy importantes y podrían representar un módulo muy usado en nuestro sistema, ya sea para la indexación del sitio, o simplemente porque es donde gran parte de la base de nuestros usuarios pasarán. Así que es necesario tener una experiencia aceptable para maximizar las oportunidades de conversión de venta

SEO

Las búsquedas no existen únicamente por parte de los clientes finales, gran parte del tráfico puede venir de robots (bots) que realizan el indexado del sitio, por ejemplo, en Google. Al proceso de optimización para el posicionamiento del sitio en los buscadores es conocido como SEO

Para nuestro caso, como los cines pueden existir en distintas ciudades (o incluso tener varios en la misma ciudad), es necesario generar un indice principal que permita navegar al bot por ciudades, y éstas redirigirlas a las paginas de "cartelera" de dicha ciudad

Búsquedas y filtros

Las búsquedas necesitan la capacidad de filtrarse por:

• Ciudad
• Cine (código o nombre)
• Tipo de sala - por ejemplo, si en un mismo cine tenemos 3D, 4D, VIP, etc.

Entonces, el mismo requerimiento sugiere que tenemos la necesidad de utilizar facetas, por lo que es utilizaremos un motor o plataforma de búsquedas, estas soluciones son optimizados para realizar las búsquedas por facetas, texto, difuso, etc.

Aquí pueden encontrar un ejemplo más desarrollado acerca de este punto

En la descripción de la arquitectura, esto quedaría de la siguiente forma:

Tiempos

Carga de contenido

Considerando que la aplicación servirá una gran cantidad de contenido variable (videos, galerías de imágenes, etc.), es necesario aplicar ciertas estrategias:

• Transformación de imágenes en distintos formatos/tamaños - Esto ayudará para cargar las imágenes de forma óptima: thumbnails para resultados de búsquedas, imágenes de mediano tamaño para la vista de la película, imagen de alta resolución para vista de lupa al seleccionar un elemento de la galería
• Imágenes adaptables/responsivas - Con HTML, podemos indicar cuales son los recursos que debemos cargar dependiendo del tamaño de la pantalla en la que se encuentra renderizado nuestro sitio
• Carga diferida de imágenes - Básicamente, cargar únicamente las imágenes que se encuentran a la vista del usuario
• Utilizar un Red de Entrega de Contenido (CDN, por sus siglas en ingles) - Esto distribuirá el contenido multimedia (o estático como CSS, por ejemplo) en distintas regiones geográficas para que sea accedido por los servidores más cercanos al cliente

En fin, para este tema, existe una gran cantidad de estrategias que podríamos considerar, pero estas son las que tendremos para la primera iteración de nuestra aplicación

Llamados al backend

Esta parte es un tanto compleja, ya que, muchas cosas pueden fallar, pero en término de integraciones: llamados al search engine, BD o cualquier otra integración con un servicio tercero

Aquí, el primer paso para mejorar el rendimiento es utilizar distintos niveles de caching. Inicialmente, sugerimos comenzar con:

• Caching a nivel de API - Podríamos darle un tiempo de vida (TTL, por sus siglas en inglés) alto a la información principal de las películas, ya que dicha información seguramente se mantendrá igual a lo largo de su existencia (titulo, cast, descripción, fecha de lanzamiento, etc.)
• Caching a nivel de aplicación - Hay ciertos accesos a la BD que podemos reducir ya que, si bien la informacion puede cambiar, no cambia con una frecuencia alta

En general, cualquier información que provenga de una fuente externa al componente del API puede potencialmente estar en su propia región de caché, por lo que podríamos incluir resultados de búsquedas, o los ascientos disponibles, aunque estos ultimos, con un TTL muy corto

De igual forma, para evitar posibles ataques, podemos incluir un firewall frente a nuestros APIs, de tal forma que podemos protegernos y reducir el riesgo de ataques (por ejemplo, de scalping)

Adicionalmente, el componente ilustrado como API puede ser decompuesto en una serie de micro servicios, los cuales tendrán que ser accedidos por un administrador de APIs

Componentes administrativos

Aplicaciones de backoffice

Para el caso de las aplicaciones de backoffice (administración) de la plataforma, es mejor separarla de los componentes que brindan el servicio a nuestros clientes finales (web/mobile), de tal forma que ese tráfico interno (por menor que pudiera ser) no genere ruido en nuestros componentes críticos

Esta aplicación puede ser incluso un monolito para esta primera iteración

Para manejar la seguridad del acceso al backoffice, es mejor restringir el acceso mediante un tunel VPN, adicional al control de roles y usuarios dentro de la aplicación misma

Cronjobs (tareas programadas)

Las tareas programadas o que deben ocurrir de manera asíncrona (verificaciones de cobros, disparos de notificaciones, indexacion de los catálogos, etc.), pueden estar en su propia aplicación, accediendo a la BD y escuchando distintos eventos emitidos por el resto de los servicios (APIs de cara al cliente, aplicaciones administrativas, etc.)

Conclusiones

Una vez mencionados todos los puntos anteriores, vemos que los sistemas de eCommerce cuentan con un nivel de complejidad elevada. Incluso pensar en un MVP de infraestructura, termina con un sistema complejo con distintos componentes

Finalmente, en esta propuesta, sugerimos el uso de micro-servicios como primera alternativa, justificada por el hecho de que, distintos componentes del sistema cumplen diferentes propósitos y seria mejor desacoplarlos para poder crecer horizontalmente de forma atómica sobre los elementos que lo necesiten, aumentando la flexibilidad de la solución