Design BookMyShow: una pregunta de entrevista sobre diseño de sistemas

Es realmente fácil buscar su película favorita en un cine, verificar la disponibilidad de asientos y reservar el boleto en la aplicación BookMyShow en solo 5-10 minutos sin mucho esfuerzo … 

Todos conocemos los servicios de BookMyShow (después de todo, a todos nos encanta ver películas… jejeje) y cómo funciona, pero ¿te imaginas cómo detrás de este gigantesco sitio web los ingenieros han usado sus cerebros para construir la compleja arquitectura de este sistema? 

¿Y si le pedimos que diseñe este sistema en tan solo 45 minutos (o menos) de un tiempo breve ( ¿es una broma? )…? No estamos bromeando, pero si usted es alguien que se está preparando para ingresar a las principales empresas gigantes tecnológicas, es posible que se enfrente a la ronda de diseño del sistema en las entrevistas (especialmente para el rol de ingeniero senior), y diseñar un sistema como BookMyShow es bastante una pregunta común de esta ronda. 

En este blog, discutiremos cómo diseñar un sistema de reserva de boletos en línea como BookMyShow, pero antes de continuar, queremos que lea el artículo » ¿Cómo descifrar el diseño del sistema en las entrevistas?» ”. Le dará una idea de cómo es esta ronda, qué se espera que haga y qué errores debe evitar frente al entrevistador. 

1. Definir objetivos y requisitos

Dígale a su entrevistador que apoyará las siguientes características. Si el entrevistador quiere agregar algunas características más, lo mencionará. 

• El portal debe enumerar las diferentes ciudades donde se encuentran los teatros. (RDBMS)
• Una vez que el usuario selecciona la ciudad, debe mostrar las películas estrenadas en esa ciudad en particular para ese usuario.
• Una vez que el usuario selecciona la película, el portal debe mostrar los cines que proyectan esa película y los programas disponibles.
• Los usuarios deberían poder seleccionar el espectáculo en un teatro en particular y reservar las entradas (soporte de pago de terceros).
• Envíe una copia de los boletos a través de una notificación por SMS o correo electrónico. (trabajadores y GCM)
• Sugerencias de películas al iniciar sesión (Hadoop y Spark Streaming con ML para obtener un motor de recomendación), notificaciones en tiempo real para el usuario sobre nuevos lanzamientos de películas y otras cosas.
• El portal debe mostrar al usuario la disposición de los asientos de la sala de cine.
• Los usuarios deberían poder seleccionar varios asientos según su elección.
• Los usuarios deben poder mantener los asientos durante 5-10 minutos antes de finalizar el pago.
• El portal debe servir los boletos de manera First In First Out
• Comentarios y calificación (Casandra)
• El sistema debe ser altamente concurrente porque habrá múltiples requests de reserva para el mismo asiento al mismo tiempo.
• El elemento central del portal son las reservas de boletos, lo que significa transacciones financieras. Por lo tanto, el sistema debe ser seguro y compatible con ACID.
• Diseño receptivo (ReactJS y Bootstrap) para ejecutar en dispositivos de varios tamaños, como dispositivos móviles, tabletas, computadoras de escritorio, etc.
• Información de la película.

2. ¿Cómo habla Bookmyshow con los teatros?

Cuando visita cualquier aplicación de terceros/agregador de entradas de cine utilizando la aplicación móvil o el sitio web, ve los asientos disponibles y ocupados para una función de cine en ese cine. Ahora la pregunta es cómo estos agregadores de terceros se comunican con los cines, obtienen la información de los asientos disponibles y se la muestran a los usuarios. Definitivamente, la aplicación necesita trabajar con el servidor del teatro para obtener la asignación de asientos y dársela a los usuarios. Existen principalmente dos estrategias para asignar los asientos a estos agregadores. 

• Se dedicará un número específico de puestos a cada agregador y luego estos puestos se ofrecerán a los usuarios. En esta estrategia, algunos asientos ya están reservados para estos agregadores, por lo que no es necesario seguir actualizando la información de asientos de todos los teatros.
• En la segunda estrategia, la aplicación puede trabajar junto con el teatro y otros agregadores para seguir actualizando la información de disponibilidad de asientos. Luego se ofrecerá el boleto a los usuarios.

3. ¿Cómo obtener la información de disponibilidad de asientos?

Existen principalmente dos formas de obtener esta información…  

• Los agregadores pueden conectarse directamente a la base de datos del teatro y obtener la información de la tabla de la base de datos. Luego, esta información se puede almacenar en caché y mostrar al usuario.
• Utilice la API del servidor del teatro para obtener la información de los asientos disponibles y reservar las entradas.

¿Qué sucederá si varios usuarios intentan reservar el mismo boleto utilizando diferentes plataformas? ¿Cómo resolver este problema? 

El servidor del teatro debe seguir una estrategia de mecanismo de bloqueo de tiempo de espera en la que un asiento se bloqueará temporalmente para un usuario durante una sesión de tiempo específico (por ejemplo, de 5 a 10 minutos). Si el usuario no puede reservar el asiento dentro de ese plazo, libere el asiento para otro usuario. Esto debe hacerse por orden de llegada. 

Si está utilizando la API del servidor de los cines, realizará muchas requests o bloqueará las llamadas de IO desde su servidor al servidor del cine. Para lograr un mejor rendimiento, debemos usar async en python o subprocesos livianos de Erlangs o Go Coroutines en Go. 

Arquitectura de alto nivel

BookMyShow se basa en una arquitectura de microservicio . Veamos los componentes individualmente. 

Equilibrador de carga

Se usa un balanceador de carga para distribuir la carga en el servidor y mantener el sistema altamente concurrente cuando estamos escalando el servidor de aplicaciones horizontalmente. El balanceador de carga puede usar múltiples técnicas para balancear la carga y estas son… 

1. Hashing consistente
2. ronda robin
3. Round Robin Ponderado
4. Conexión mínima

Almacenamiento en caché frontend y CDN

Hacemos almacenamiento en caché de frontend usando Varnish para reducir la carga de la infraestructura de backend. También podemos usar CDN Cloudflare para almacenar en caché las páginas, la API, el video, las imágenes y otros contenidos. 

Servidores de aplicaciones

Habrá múltiples servidores de aplicaciones y BookMyShow usa Java, Spring Boot, Swagger e Hibernate para los servidores de aplicaciones. También podemos optar por servidores basados ​​en Python o NodeJS (según los requisitos). También necesitamos escalar estos servidores de aplicaciones horizontalmente para soportar la carga pesada y manejar muchas requests en paralelo.  

Búsqueda elástica

La búsqueda elástica se utiliza para admitir las API de búsqueda en Bookmyshow (para buscar películas o programas). La búsqueda elástica se distribuye y tiene API de búsqueda RESTful disponibles en el sistema. También se puede utilizar como un motor de análisis que funciona como un motor de búsqueda a nivel de aplicación para responder a todas las consultas de búsqueda desde la interfaz. 

almacenamiento en caché

Para guardar la información relacionada con las películas, el orden de los asientos, los teatros, etc., necesitamos usar el almacenamiento en caché . Podemos usar Memcache o Redis para el almacenamiento en caché para guardar toda esta información en Bookmyshow. Redis es de código abierto y también se puede usar para el mecanismo de bloqueo para bloquear los boletos temporalmente para un usuario. Significa que cuando un usuario intenta reservar el boleto, Redis bloqueará los boletos con un TTL específico. 

Base de datos

Necesitamos usar bases de datos RDBMS y NoSQL para diferentes propósitos. Analicemos qué necesitamos en nuestro sistema y qué base de datos es adecuada para qué tipo de datos… 

• RDBMS: Hemos mencionado que necesitamos la propiedad ACID en nuestro sistema. Además, tenemos países, ciudades, teatros en ciudades, múltiples pantallas en estos cines y múltiples filas de asientos en cada pantalla. Así que aquí está claro que necesitamos una representación adecuada de la relación. Además, tenemos que manejar la transacción. RDBMS es adecuado para estos casos. El portal tendrá una gran cantidad de lecturas, por lo que debemos fragmentar los datos por Geo o debemos usar la arquitectura maestra-maestra esclava. Los esclavos se pueden usar para leer y el maestro para escribir.
• NoSQL: también tenemos una gran cantidad de datos, como información de películas, actores, equipo, comentarios y reseñas. RDBMS no puede manejar tanta cantidad de datos, por lo que necesitamos usar la base de datos NoSQL que se puede distribuir. Cassandra puede ser una buena opción para manejar esta tonelada de información. Podemos guardar múltiples copias de datos en múltiples Nodes implementados en múltiples regiones. Esto asegura la alta disponibilidad y durabilidad de los datos (si un Node se cae, tendremos datos disponibles en otros Nodes).
• Use HDFS para ejecutar consultas para análisis.

Trabajadores asíncronos

La tarea principal del trabajador Async es ejecutar tareas como generar el pdf o png de las imágenes para boletos reservados y enviar la notificación a los usuarios. Para notificaciones automáticas, notificaciones por SMS o correos electrónicos, debemos llamar a las API de terceros. Estos son IO de red y agrega mucha latencia. Además, estas tareas que consumen mucho tiempo no se pueden ejecutar de forma síncrona. Para resolver este problema, tan pronto como el servidor de la aplicación confirme la reserva de los boletos, enviará el mensaje a la cola de mensajes, un trabajador libre tomará la tarea, la ejecutará de forma asíncrona y proporcionará la notificación por SMS, otras notificaciones o correo electrónico a los usuarios. RabbitMQ o Kafka se pueden usar para Message Queuing System y Python celerypuede usarse para trabajadores. Para la notificación del navegador o la notificación del teléfono, utilice GCM/APN. 

Inteligencia de negocios y ML

Para el análisis de datos de información comercial, necesitamos tener una plataforma Hadoop . Todos los registros, la actividad del usuario y la información se pueden volcar en Hadoop y, además, podemos ejecutar consultas PIG/Hive para extraer información como el comportamiento del usuario o el gráfico del usuario. ML se usa para comprender el comportamiento del usuario y generar recomendaciones de películas, etc. Para el análisis en tiempo real, podemos usar Spark Streaming. También podemos descubrir la estrategia de detección y mitigación de fraude utilizando el motor de procesamiento de flujo  Spark o Storm .

Gestión de registros

La pila ELK (ElasticSearch, Logstash, Kibana) se utiliza para el sistema de registro. Todos los registros se envían a Logstash. Logstash recopila datos de todos los servidores a través de Archivos/Syslog/socket/AMQP, etc. y, en función de un conjunto diferente de filtros, redirige los registros a Queue/File/Hipchat/Whatsapp/JIRA, etc. 

Trabajo paso a paso 

• El cliente visita el portal y filtra la ubicación. Para encontrar la ubicación podemos usar GPS (si es un teléfono móvil) o ISP (si es una computadora portátil). Luego, se sugerirán al usuario los cines y las películas estrenadas en esos cines. Los datos se proporcionarán desde el motor de recomendaciones DB y ELK.
• Los usuarios seleccionan la película y verifican los diferentes horarios de las películas en todos los cines cercanos.
• Los usuarios seleccionan una fecha y hora en particular para una película en el cine de su elección. La información de los asientos disponibles se obtendrá de la base de datos y se mostrará al usuario.
• Una vez que el usuario selecciona el asiento disponible, BMS bloquea el asiento temporalmente durante los próximos 10 minutos. BMS interactúa con la base de datos de los teatros y bloquea el asiento para el usuario. El boleto se reservará temporalmente para el usuario actual y para todos los demás usuarios que utilicen diferentes agregadores o aplicaciones, el asiento no estará disponible durante los próximos 10 minutos. Si el usuario no puede reservar el boleto dentro de ese plazo, el asiento se liberará para los otros agregadores.
• Si el usuario continúa con la reserva, verificará la factura con la opción de pago y luego del pago a través de la pasarela de pago, se notificará al servidor de la aplicación sobre el pago exitoso.
• Después del pago exitoso, el cine generará una identificación única y se la proporcionará al servidor de la aplicación.
• Usando esa identificación única, se generará un boleto con un código QR y se mostrará una copia del boleto al usuario. Además, se agregará un mensaje a la cola para enviar la copia de la factura del boleto al usuario a través de una notificación por SMS o correo electrónico. El boleto tendrá todos los detalles, como la película, la dirección del teatro, el horario, el número de teatro, etc.
• A la hora de la película, cuando el cliente visite el cine, se escaneará el código QR y el cliente podrá ingresar al cine si la identificación coincide tanto en el boleto del cliente como en el boleto del teatro.

API necesarias 

• ObtenerListaDeCiudades()
• ObtenerListaDeEventosPorCiudad(CityId)
• ObtenerUbicacionesPorCiudad(CityId)
• ObtenerUbicacionesPorEventoyCiudad(cityid, eventid)
• Obtener eventos por ubicación y ciudad (ID de ciudad, ID de ubicación)
• GetShowTiming(eventid, locationid)
• GetAvailableSeats(eventid, locationid, showtimeid)
• VarifyUserSelectedSeatsAvailable(eventid, locationid, showtimeid, asientos)
• Bloquear asientos seleccionados por el usuario()
• LibroUsuarioSeleccionadoAsiento()
• GetTimeoutForUserSelectedSeats()

Tablas RDBMS 

• Lugar (para guardar los datos jerárquicos de cualquier país, estado, ciudad y calle similar a un cine)
• Teatro
• Pantalla
• Tier (nivel de asientos)
• Asientos
• Película
• Ofertas
• Boleto
• Usuario

Relación entre tablas RDBMS:

• Uno a muchos: Lugar y teatro.
• De uno a muchos: Teatro y pantalla
• Uno a muchos: pantalla y nivel
• De uno a muchos: niveles y asientos
• Uno a uno: pantalla y película
• Uno a muchos: Usuario y Tickets
• De uno a muchos: boletos y asientos

Tablas NoSQL

No habrá ninguna relación entre estas tablas. 

• Comentarios
• Calificaciones
• Información de la película
• Trailers o Galería
• Artistas
• Reparto y equipo
• Reseñas
• Datos analíticos 

Tecnologías utilizadas por Bookmyshow

• Interfaz de usuario: ReactJS y BootStrapJS
• Lenguaje y marco del servidor: Java, Spring Boot, Swagger, Hibernate
• Seguridad: Seguridad Primavera
• Base de datos: MySQL
• Servidor: Tomcat
• Almacenamiento en caché: En memoria caché Hazelcast.
• Notificaciones: RabbitMQ. Una cola de mensajes distribuidos para notificaciones push.
• API de pago: las más populares son Paypal, Stripe, Square
• Implementación: Docker y Ansible
• Repositorio de código: Git
• Registro: Log4J
• Gestión de registros: pila ELK
• Equilibrador de carga: Nginx

Muchos candidatos temen más la ronda de diseño del sistema que la ronda de codificación. La razón es… que no tienen la idea de qué temas y compensaciones deben cubrir dentro de este marco de tiempo limitado. Deben tener en cuenta que la ronda de diseño del sistema es extremadamente abierta y no existe una respuesta estándar. Para las mismas preguntas, la conversación con los diferentes entrevistadores puede ser diferente. Su experiencia práctica, su conocimiento, su comprensión del sistema de software moderno y cómo se expresa claramente durante su entrevista son muy importantes para diseñar un sistema con éxito.