El algoritmo detrás del chat en Platzi Conf 2021

Hoy te contaré un par de cosas que el equipo de Producto en Platzi, estuvo iterando para poder brindarles la mejor experiencia dentro de la plataforma.

La 15ava edición de Platzi Conf se desarrolló completamente en linea, todos los equipos trabajaron en sinergia para poder superar los retos y brindarles el contenido de mayor valor en la región para así seguir impulsando nuestra economía, en este artículo me enfocaré especialmente en un solo punto.

Soy ebar0n inicié en el equipo de Producto como Backend y actualmente soy DevOps Architect.

Platzi se construyó bajo una base Core escrita en Python con Django, la cual permitió tener en su momento mucha velocidad y poder dar valor con rápidas iteraciones, pero a medida que el equipo creció, fue necesario de forma natural irnos moviendo a una arquitectura más escalable que facilitara el trabajo colaborativo en microservicios, que precisamente es sobre lo que les quiero hablar hoy, nuestro sistema orquestado para mantener la experiencia del chat en Platzi Live.

El sistema del Chat que actualmente sirve Platzi, está construido in house con 7 componentes o microservicios independientes, donde tenemos código escrito en lenguajes de programación como Python, Javascript, Go y Rust, orquestados con Kubernetes, permitiéndonos ser elásticos para poder crecer lo necesario y volver al mínimo cuidando nuestra facturación; además de un par de servicios Core de AWS, incluso aprovechamos al máximo las ventajas de nuestro CDN - Cloudflare, usando estrategias de caché agresiva y el poder de los Workers, (al final del día no es necesario tener tanto cómputo si puedes sacarle partido a ese detalle, pero eso es un Plus, dejemóslo para profundizar en otro artículo)

Dentro de esos 7 componentes profundizaré en uno solo: MS-Daredevil, ¿y ese nombre? ¿Qué es eso?, Bueno en términos menos ñoños, nuestro Clasificador de mensajes, revelando una de sus múltiples sub rutinas, y aquí esto se pone interesante, ustedes podrán pensar que no es la gran cosa, pero realmente no se detectó hasta hacer pruebas de carga e irnos a escala, simplemente no fue prioridad hacerlo antes, siempre vamos mejorando sobre la marcha con nuestro objetivo se entregar valor lo mas rápido posible, recoger datos, iterar y continuar.

Entonces para poder describir la solución primero partamos del planteamiento, problema u oportunidad de mejora, eso que tanto nos gusta, porque es lo que debemos resolver y nos hace crecer.

La oportunidad de mejora

Platzi crece cada día, soñamos con ver el acceso a la educación online efectiva súper masificada, y en esta edición de la Conf nos preparamos más o menos para 150 mil estudiantes simultáneos en las salas de la Conf (4 salas), siendo uno de los componentes clave el chat, nuestra comunidad es lo más valioso y tiene mucha importancia para todo el equipo en Platzi, poder facilitar esa interacción y conectarlos, mientras disfrutaban de todas las charlas en vivo… allí entramos en detalles.

¿Se imaginan qué pasa cuando 150 mil estudiantes escriben un mensaje? ¿En un segundo?, vámonos al ejemplo de carga mínima; tú, el/la/elle que está leyendo esta publicación, escribe un mensaje en el chat… desde que le das enviar, ese mensaje viaja al servidor, pasa por varios procesos hasta que finalmente es distribuido de regreso a 150 mil estudiantes o conexiones, un solo mensaje, es un chat en tiempo real, pero ahora ¿que pasa cuando todos escriben al mismo tiempo?, 150 mil mensajes replicados a 150 mil estudiantes, multipliquemos, nos da 22.500 millones de mensajes replicados, es una locura, ¿cuánto tiempo tardarían en difundirse?, y solo caímos en cuenta del problema palpable hasta la ejecución de unas pruebas de estrés cargadas de fuego purificador, al enviar trafico exagerado, llegaban olas de mensajes con retrasos importantes, y esto fue vital notarlo, todo debe probarse y llevarse al extremo, al final del día si no conoces esos límites, le das mucho pie a la incertidumbre y cualquier cosa puede salir mal, y así lo hagas créeme que lo que ha de fallar, fallará, está escrito, lo hemos vivido.

A 2 días antes de la Conf, eso aún funcionaba así, pero que va, no existe poder humano que permita leer 150mil mensajes en un segundo, ni incluso aquellas personas con la habilidad desarrollada de lectura rápida, y ademas tampoco tiene sentido ocupar esa cantidad de transferencia de datos, pero entonces ¿qué hacemos?

Revelando algunos detalles

Esos 150 mil mensajes si deben llegar a servidor, y deben ser guardados (los persistimos en lotes para no saturar el motor de base de datos), los necesitamos, son nuestra mina de metales preciosos para poder calcular métricas, y saber algunas cosas como aquellos momentos top de cada charla (por irnos a un ejemplo simple).

Pero ¿qué hicimos?, como cada componente tiene una función muy específica, simplemente añadimos algo de código en nuestro clasificador, justo antes de enviarlo al servicio de difusión.

Partimos de un rate limit llegando hasta muestreos estadísticos (ya vamos a ver por qué un rate limit por sí solo no era viable).

Partiendo de esa ilustración, si usamos un rate limit en tiempo llamado T y si decimos que ese valor tope de mensajes enviados es 500, al paso de los primeros 500 mensajes simplemente el chat dejaría de moverse por que se acabo la cuota en el primer segundo, y esa idea de “en tiempo real” se degradaría porque hasta los T segundos después no vería mensajes moverse, entonces no se ajusta a lo que deseamos, así que, luego de ese número tope, partimos de un porcentaje, una cantidad porcentual de mensajes que si deberían seguir difundiéndose y que el chat pueda seguir sintiéndose en vivo, o en otras palabras, muestreos, seguir difundiendo muestreos de mensajes.

Pero, ¿cuál porcentaje es el adecuado? 30%? 10%? para definir el muestreo 🤔 … ninguno de los 2, el 10% de 150 mil es 15 mil, aún sigue siendo demasiado, en unos pocos segundos tú puedes escribir N mensajes, entonces, si 149mil estudiantes envían solo 6 mensajes, ya estamos hablando de 1 millón de mensajes que tu recibirás en unos pocos segundos, así que, el algoritmo debe ser adaptativo, porque no queremos que sea el 10% de los 500 mensajes en rate limit, queremos que sean muestreos del 10% de todos los mensajes entrantes, y que por estadística a cada mensaje se le obtenga su valor ponderado si se encuentra entre el % aceptable o no, para poder ser replicado.

Así luego de superar el valor tope máximo, por algunas escalas, el porcentaje de muestreo debe irse recalculando para tomar cada vez un muestro más y más pequeño, y así, seguir teniendo tráfico de mensajes pero de una forma más controlada, y cada estudiante pueda seguir teniendo interacción segundo a segundo dentro de la comunidad, no lo verán todo, pero la estadística nos asegura que verán algo más humanamente procesable.

En resumen, nuestro chat sigue siendo real time, pero luego de ciertos umbrales de mensajes por segundo, el algoritmo comienza a tomar muestreos a difundir y así brindarte la mejor experiencia.

Si te gustaron estos detalles sin irnos tan profundo como ver código, dale like y comparte!

Ahora te pregunto: ¿Notaste algo diferente durante la Conf? o no solo la Conf, ¿qué fue lo último nuevo que notaste en la plataforma? Algunas cosas son invisibles, pero esta fue solo una de las tantas mejoras que se implementan con el día a día, en Platzi hacemos despliegues continuos y en un solo día enviamos muchas mejoras.

Déjame en los comentarios que mejora de Platzi ha cambiado tu experiencia dentro la plataforma.