En este artículo, el responsable de Tecnología del Dominio de PIN-UP Global, Ilya Galashko, aborda los puntos clave que los operadores deben tener en cuenta durante la fase de desarrollo de una plataforma de apuestas. Según el ejecutivo, estas soluciones le ayudarán a "evitar fracasos, ahorrar su presupuesto y mantener su tranquilidad”.
No es ningún secreto que, en medio de grandes acontecimientos deportivos como la Copa del Mundo o la Super Bowl, muchas plataformas de apuestas se enfrentan a enormes cargas. El resultado son fallos del sistema, retrasos en el procesamiento de las apuestas o incluso la denegación total del servicio. Por supuesto, es imposible eliminar por completo los riesgos. Pero crear un sistema estable y escalable que pueda hacer frente al prime time es un objetivo alcanzable. En este artículo, les hablaré de los puntos clave a tener en cuenta en la fase de desarrollo de una plataforma de apuestas. Estas soluciones les ayudarán a evitar fracasos, ahorrar su presupuesto y mantener su tranquilidad.
Los puntos de fallo son elementos clave del sistema que, si fallan, hacen que tu plataforma no esté disponible total o parcialmente. Pueden ser bases de datos, microservicios, colas de mensajes, dependencias externas o componentes de infraestructura. Si estos nodos fallan, la lógica empresarial se detiene, los usuarios pierden el acceso y la empresa pierde ingresos y reputación.
El primer paso es identificar qué componentes son cruciales para la viabilidad de la plataforma. El segundo, es comprender lo vulnerable que es cada uno y qué consecuencias tendrá su fallo. Por ejemplo, si tiene un microservicio independiente responsable de aceptar apuestas, su estabilidad es crítica. Si deja de funcionar tras una actualización, el sistema deja de aceptar apuestas, lo que significa que la empresa deja de ganar dinero.
Conocer estas dependencias les permitirá:
Cuanto antes identifique los principales puntos de fallo, más fácil le resultará tomar decisiones técnicas fundamentadas en todas las fases de desarrollo.
Determinen qué datos almacenan y cómo los transfieren a través de la red. No transfieran cosas de más, porque cada parámetro extra les ralentiza y sobrecarga la infraestructura. Optimicen sus modelos de datos. Para transferir datos a través de la red, es necesario serializarlos y deserializarlos, lo que consume muchos recursos. Cuando trabajen con corredores de mensajes (como Kafka o RabbitMQ), elijan un patrón de enrutamiento adecuado. No apliquen fan-out sin sentido sólo porque “es más fáciln. Añadir información extra a los modelos de datos “por si acaso” puede sobrecargar tanto a los brokers como a los clientes que no necesitan esta información, y provocar retrasos en la entrega.
La base de datos es el núcleo de toda la plataforma y una de las causas más comunes de fallo en los sistemas de apuestas. El problema viene del hecho de que la arquitectura de la base de datos en muchos sistemas se creó en las primeras fases de desarrollo, cuando nadie pensaba en escalar. Reescribirla más tarde resulta caro, arriesgado y doloroso.
Eviten la estrategia de “todo en una base de datos”. En su lugar, separen las áreas de responsabilidad. Por ejemplo, utilicen una base de datos separada para las apuestas y los cálculos, y otra para el árbol de deportes. Esta separación aumenta la tolerancia a fallos y reduce el riesgo de degradación total del sistema si falla uno de los subsistemas. Además, hay que tener en cuenta que las bases de datos de apuestas son sistemas con un gran volumen de registros. Diseñen esquemas de datos para tal carga. No almacenen en la base de datos elementos que no se utilicen: sólo ralentiza la ejecución de las consultas y consume recursos. Utilicen la memoria caché. Si siguen extrayendo datos directamente de la base de datos para cada operación de lectura durante el horario de máxima actividad, probablemente tengan un problema de caché. En PIN-UP Global, hemos acelerado drásticamente la entrega de información al cliente mediante la descarga de la base de datos a través del almacenamiento óptimo de datos y el almacenamiento en caché configurado correctamente.
Durante el desarrollo, a menudo resulta tentador trasladar parte de la lógica empresarial al lado del cliente. Por ejemplo, ordenar, agrupar, filtrar o buscar datos. Parece una solución fácil, sobre todo si se utilizan frameworks modernos. Sin embargo, en realidad, puede afectar gravemente al rendimiento, especialmente cuando se trata de clientes web en el navegador.
Los navegadores no son entornos multihilo. Todas las operaciones se realizan secuencialmente, y a medida que crece la cantidad de datos o la complejidad de la lógica, la interfaz empieza a ralentizarse. La carga de la página se ralentiza, la interacción con los elementos deja de responder y la experiencia general del usuario es negativa.
El navegador ya está agotando recursos en la carga de código, scripting y renderizado. Si además se añade lógica de negocio, los retrasos aumentan. Esto es especialmente grave para los usuarios con dispositivos débiles o Internet inestable.
Recuerden que siempre pueden aumentar la capacidad del servidor, pero no la del cliente.
Las pruebas de carga son una de las formas más eficaces de identificar los puntos débiles de un sistema antes de que se manifiesten en la realidad. Una plataforma de apuestas no es un sitio estático. Incluso con un pequeño número de usuarios, procesa miles de peticiones cada segundo. Los eventos deportivos en directo comienzan y terminan, las cuotas se actualizan, se realizan cálculos y se envían notificaciones.
Es importante no limitar las pruebas únicamente al crecimiento del número de usuarios. La carga real no sólo procede de la conexión, sino también de la intensidad de los eventos simultáneos. Simulen escenarios complejos: inicios simultáneos de partidos, actualizaciones masivas de datos, muchas apuestas paralelas. Estas simulaciones le mostrarán hasta qué punto su sistema es escalable y dónde están sus límites reales.
Las pruebas de carga deben realizarse con regularidad. Nosotros, en PIN-UP Global, las realizamos al menos una vez al mes, lo que nos permite evitar incidencias en horas punta. El hecho de que el sistema diera buenos resultados hace tres meses no garantiza nada hoy. Los códigos cambian, la lógica se vuelve más compleja, se añaden nuevas dependencias y cada detalle de este tipo puede provocar cuellos de botella. Además, durante las pruebas de carga a menudo se detectan puntos de fallo que quizá ni siquiera sospechábamos.
Por último, me gustaría decir que no hay que tener miedo a experimentar con algoritmos de optimización o equilibrio de carga. Como he dicho antes, cada milisegundo cuenta en las apuestas y si crees que optimizar para 50 milisegundos un martes con 100 personas conectadas no tiene sentido, en prime time esta cifra puede salvar tu sistema de la sobrecarga.