Desarrollar software de marketing de afiliación para la plataforma Quints

Hay un gran número de negocios de juegos de azar y apuestas en Internet, desde casinos hasta corredores de apuestas deportivas. Cada día, miles de jugadores pasan por ellas, realizando apuestas y otras actividades. Los jugadores no vienen solos a estos casinos de servicios de apuestas, sino que lo hacen a través de intermediarios que distribuyen enlaces (normalmente, mediante banners en Internet).

Si un jugador se registra en un casino a través de un tercero o empresa, un determinado porcentaje del gasto del jugador se paga al intermediario. Quints se creó para aprovisionar soluciones de seguimiento de afiliados para empresas de apuestas que gestionan toda su información sobre los jugadores y las personas que los invitaron.

Hay tres participantes principales en los servicios de estadísticas de afiliados de juegos de azar en línea de Quints:

• Clientes: agentes de casinos en línea, agentes de apuestas o incluso tiendas de Internet.
• Jugadores: las personas que juegan en casinos en línea, realizan apuestas con corredores de apuestas o hacen compras en línea.
• Afiliados: los intermediarios que llevan jugadores a los clientes, principalmente mediante anuncios. Los clientes contratan a distintos afiliados para recomendarles jugadores, y los afiliados reciben una recompensa a cambio.

Sin embargo, para pagar los premios a los afiliados, los clientes necesitan conocer cuántos jugadores trajo cada uno de los afiliados y cuánto se gastaron en total dichos jugadores. Como proveedor de software de juegos de azar en línea, aquí es donde Quints resulta útil.

Quints es un nivel intermedio entre los clientes y los afiliados. Es un sistema para recopilar estadísticas sobre marketing de afiliación y trabajar con estos datos mediante gráficos, informes, etc. Tanto los clientes como los afiliados usan Quints, por lo que tiene dos tipos de cuentas de cliente.

Primeros pasos

Quints genera un enlace especial para el afiliado que inserta en sus anuncios. Cuando un jugador hace clic en el enlace, primero es dirigido a Quints. El sistema captura estos datos y lo redirige al cliente.

Cuando la plataforma de marketing de afiliación recibe una amplia variedad de datos, se usan fórmulas específicas para calcular los pagos de afiliados para cada jugador. Por lo tanto, Quints es básicamente un tipo de agregador o calculadora de estadísticas de juego.

Los propietarios de Quints se pusieron en contacto con Evrone con un producto ya desarrollado de dos años de antigüedad para la generación de informes de afiliados y administración de clientes. La aplicación tenía mucho código heredado, y el 70-80 % de las funciones ya existían. Sin embargo, durante nuestro trabajo conjunto en el proyecto, una gran parte se finalizó y mejoró. Ahora, nuestro equipo trabaja en la optimización e implementación de nuevas características para convertir el proyecto en algo brillante.

La tarea

El principal reto de Quints era que no se trataba de un solo proyecto, sino de varios: uno para cada cliente, y cada uno con sus propias características. El núcleo del proyecto ya estaba desarrollado; pero, cada vez que se conectaba un nuevo cliente, se creaba una bifurcación separada para este. Y, a partir de esta bifurcación, se implementó una aplicación separada para ese cliente específico.

En resumen, para 10 clientes, teníamos 10 bifurcaciones del proyecto principal, que básicamente se convertían en 10 proyectos distintos. Y, en el futuro, cada uno de los clientes quería ser capaz de mejorar o modificar los proyectos individuales por su cuenta. Como resultado, en lugar de un proyecto que tenía que desarrollarse y proporcionar asistencia, recibimos 10 proyectos, y se espera que ese número crezca a medida que Quints sigue incorporando a nuevos clientes.

Implementar nuevas características era muy difícil porque todos los proyectos eran ligeramente distintos entre sí. Y, al realizar la implementación, debían tenerse en cuenta estas diferencias específicas. El pronóstico para esa arquitectura parecía abrumador, ya que Quints necesitaba atraer nuevos clientes, pero cada cliente nuevo significaba aún más trabajo.

La solución

Cuando nos unimos al proyecto, lo primero que empezamos a hacer fue cambiar el método de la arquitectura. Empezamos a migrar (y aún seguimos migrando) hacia un proyecto unificado. Queríamos asegurarnos de que todos los clientes tenían el mismo código, y las diferencias solo estaban en las configuraciones y ajustes. Esto nos permitiría desarrollar solo un proyecto, no tantos proyectos como clientes.

Durante la vida del proyecto, también llegamos a la conclusión de que faltaba un nivel intermedio entre el cliente y la aplicación en sí. Por lo tanto, creamos un servicio que permitía a los clientes enviarnos datos sin formato; a continuación, el servicio de almacenamiento de datos recopila y prepara esos datos en el formato necesario para que Quints pueda trabajar con estos. Permitía a los clientes no perder tiempo en la agregación en su lado. Este es un servicio de alta carga que intercambia una cantidad de datos bastante grande, y ahora funciona a la perfección.

Junto con el equipo de Quints, preparamos la documentación sobre el trabajo del proyecto. En un principio, la aplicación no tenía ningún tipo de documentación. Intentamos que todas las pruebas del proyecto lleguen al estado correcto. En general, el proyecto está en un proceso de intensa refactorización de las funciones.

Pila tecnológica

El proyecto no es monolítico y está dividido en front-end y back-end. El back-end está escrito en Ruby on Rails, y el front-end en Angular.js. El front-end y el back-end son aplicaciones separadas que se comunican a través de la API proporcionada por el back-end.

Infraestructura y pila tecnológica:

• Infraestructura:Kuber, DO, Prometheus (autohospedado), ELK (autohospedado), Amazon, CloudFlare
• Front-end: SPA (single page application) on Angular.js 
• Back-end: Ruby 2.3, Rails 4.2, Postgres 9.x, ClickHouse, Sidekiq Enterprise
• Adicional: Gitlab (self-hosted), Jira, Confluence, Sentry (autohospedado), Mailgun, Testrail, Quints VPN

Inicialmente, el proyecto se implementó en servidores a través de Capistrano, pero poco a poco nos apartamos de esto hacia Docker y Docker Compose, y posteriormente a Kubernetes. Participamos en la toma de decisiones de contratación estratégica y creamos una dirección de DevOps independiente.

Para supervisar el estado de la aplicación, usamos:

• Sentry para supervisar las excepciones en la aplicación
• Grafana para la supervisión de recursos de servidores

Además, el proyecto depende en gran medida de Gitflow. Para cada cliente, se crea una bifurcación de código del proyecto principal. Se creó un script especial que obtiene todos los cambios del repositorio principal mediante fork-heirs. Sin embargo, no resulta fácil de usar y estamos intentando apartarnos de dicha implementación.

Se registraron varias veces ataques DDoS contra el proyecto. Por lo tanto, se añadió rack-attack gem y se configuró contra ataques de fuerza bruta de contraseña y limitación de peticiones. Actualmente, impide los ataques DDoS.

Poco a poco, estamos implementando nuevas soluciones de optimización de la experiencia del cliente. Como el cálculo de los datos en la aplicación está ofuscado, tanto en el código como en las consultas SQL, la optimización afecta a estas dos direcciones. Al optimizar, usamos herramientas estándar, como RSpec-benchmark, RubyProf, StackProf y MemoryProfiler.

Teniendo en cuenta la importación de datos del cliente, implementamos la interacción con distintos orígenes de datos. De forma predeterminada, la aplicación funcionaba con SFTP, pero ahora puede funcionar con Google Cloud Storage, así como obtener datos directamente desde la API del cliente.

Retos principales

Uno de los problemas a los que nos enfrentamos fue el cálculo incorrecto de estadísticas, debido a los datos incorrectos del cliente, o bien a un problema interno en la aplicación. Por ejemplo, finales del año pasado, se incrementó significativamente la actividad en varios subproyectos. Había crecido tanto, que la aplicación no podía estar al día con los cálculos. Tuvimos que supervisar la operación de la aplicación durante un día completo y, en situaciones de emergencia, resolver de forma manual la información recibida.

Además, como mencionamos anteriormente, Quints ha experimentado periódicamente ataques DDoS. Sin embargo, nuestro equipo de DevOps y el responsable de equipo solucionaron rápidamente estos intentos para relanzar el proyecto, que ya no ha tenido problemas de disponibilidad. También encontramos un problema con un hacker que se registró en el sistema y empezó a enviar tráfico generado automáticamente. Pero rápidamente lo identificamos y bloqueamos dicha actividad.

Sistema de distribución del tráfico

Al principio, el monolito de Rails tenía dificultades para gestionar una carga de tráfico de anuncios de 600 RPS (clics y visualizaciones de banners). Además, la base de datos de Postgres estaba creciendo, y tenía complicaciones para gestionar grandes cantidades de datos, e incluso particionarla no sirvió de mucho.

Uno de los clientes corporativos clave de Quints quería implementar nuevos requisitos para carga y una función. La nueva función tendría que incluir una configuración flexible del redireccionamiento del tráfico según distintas reglas de enrutamiento. Por ejemplo, según la región de los usuarios finales, determinada por la solicitud IP, el período de la campaña de publicidad y otros ajustes, era necesario redirigir a un recurso específico. Por lo tanto, decidimos implementar un sistema de distribución de tráfico (TDS), que sirve como un intermediario que compra y vende tráfico entre sitios web.

Queríamos que el sistema soportara una carga de trabajo como mínimo de 2000 RPS, y decidimos implementar TDS como un sistema separado fuera del monolito. Se diseñaron desde cero varias opciones de arquitectura, y algunas funciones se transfirieron del monolito al nuevo sistema. Implementamos el TDS basándonos en una arquitectura de microservicios con el micromarco Roda (Ruby). Para el almacenamiento de datos de tráfico sin formato de clics y visualizaciones, usamos el DBMS de Clickhouse, que puede gestionar enormes cantidades de datos por registro y ejecutar consultas de análisis para la agregación de datos a gran velocidad. También se integró Kafka para proporcionar datos a Clickhouse. Kafka también se usó para transferir datos agregados al sistema principal monolítico de Quints.

Como resultado:

• Implementamos la función de TDS
• Habilitamos todos los componentes de TDS para que fueran escalables horizontalmente
• Permitimos que soportara la carga de 4000 RPS en un nodo (podemos incrementar horizontalmente el número de nodos al aumentar el rendimiento del sistema)
• Movimos parte de las funciones del monolito a un nuevo sistema que es más fácil de modificar, mantener y ampliar
• Redujimos la carga en la aplicación monolítica principal
• Redujimos la carga en el almacén principal de Postgres

El resultado

Aparte de desarrollar y proporcionar asistencia para el sistema en sí, también participamos en la creación de:

• Un paquete de documentación técnica para el producto de software
• Procesos para predecir el plazo de entrega de características y publicación de proyectos
• El proceso de entrevistar y contratar a nuevos empleados
• Procesos completos de incorporación, incluyendo un plan de desarrollo para estudiar documentación de texto y vídeo, asesoramiento y comentarios
• Proceso de salida de empleados
• Un proceso para crear informes mensuales para clientes finales

Se invirtió mucho tiempo y esfuerzo para crear los procesos de interacción y desarrollo. De forma conjunta con Quints, intentamos establecer el uso compartido de conocimientos y la conservación de registros.

El proyecto ha obtenido resultados excelentes, y el cliente quedó tan impresionado con nuestras contribuciones que decidió incrementar la presencia de Evrone en el proyecto. Ahora, el equipo de Evrone en el proyecto de Quints incluye a 12 desarrolladores de back-end, 3 ingenieros de control de calidad, un gestor de cuentas y un gestor de proyectos que está implicado directamente en la gestión del equipo de proyectos en su conjunto, que incluye a más de 20 especialistas.

Si quiere automatizar un negocio de afiliación o necesita más información sobre cómo usar un agregador en la administración de empresas de juegos de azar, use el formulario siguiente para ponerse en contacto con nosotros.