A principios de octubre con la nueva explosión del dólar Santander Tecnología Argentina innovó presentando una fila virtual a fin de amortiguar el tráfico de personas.
David Pedreira, CTO de Santander Tecnología, cuenta esta en esta artículo cómo fue el proceso de creación de esta útil herramienta:
El 1 de octubre sorprendimos a nuestros clientes poniendo un cartel de espera en la entrada de Online Banking. ¿Por qué hicimos esto? Y ¿cómo lo hicimos?
Desde hace tiempo, se aglomeran decenas de miles de clientes para comprar dólares en los primeros minutos de la jornada cambiaria. Esta situación atípica pone a prueba nuestra arquitectura, diseñada para ser resistente pero a la que le cuesta soportar picos breves que multiplican la cantidad de operaciones normales.
Empezamos una carrera tecnológica para poder cubrir esos picos. Necesitábamos encontrar una solución para satisfacer esa aglomeración. Mejoramos y optimizamos toda nuestra arquitectura. Pero, cada mes, cada primer día, nos decepcionábamos. Los picos superaban durante unos minutos la capacidad de nuestra arquitectura y nos caíamos.
El 1 de septiembre estábamos convencidos de que habíamos hecho los deberes. Estábamos listos. Había expectación y orgullo por el gran trabajo realizado las semanas anteriores. Como todos los primeros, nos habíamos juntado desde las 7.00 am para seguir la evolución del día. La mañana avanzaba sin problemas y todo tenía buena pinta. A las 10.30 la realidad nos golpeó con dureza. Empezaron a teñirse de rojo nuestros tableros de control. La web dejó de responder. Los siguientes minutos fueron una lucha para restaurar el sistema. Todos sentimos el balde de agua fría.
Ese mismo mediodía hicimos un ejercicio de “postmortem”. Nos juntamos y analizamos porqué nos habíamos caído. Había un límite muy concreto en el procesamiento del mainframe al que habíamos llegado. Para resolverlo debíamos multiplicar su capacidad de proceso. Eso implicaba una inversión muy grande que no tenía sentido, solo iba a ser usada unos minutos cada mes, y que además, no podía hacerse en los 29 días que nos quedaban hasta el 1 de octubre. Optimizar aún más nuestro software tampoco aseguraba el éxito. Las ideas iban y venían. Ninguna parecía suficiente. Y en ese momento, se hizo una pregunta que lo cambiaría todo. “¿Y si hacemos lo mismo que hacen los sitios de venta de entradas?”
De tráfico, semáforos y colas
Los sitios de venta de entradas se enfrentan a un problema muy similar al que tenemos nosotros esos primeros minutos del mes. La mayor parte del tiempo tienen una cantidad de ventas determinada, pero cuando llega un gran concierto o un partido popular, tienen que hacer muchas en muy poco tiempo. Lo que hacen es crear una cola a la entrada del sitio para amortiguar esa demanda.
Todos los sistemas técnicos tienen una capacidad máxima. Se parecen a las carreteras. Una carretera de un carril se congestiona si tiene una cantidad de tráfico. Una solución es agregar más carriles, construir una ruta. Esa ruta puede soportar aún más tráfico, pero, cuando llegan muchísimos autos, se congestiona de nuevo. Las soluciones tecnológicas son similares. Podemos agregar capacidad de proceso (carriles), pero eventualmente se llega a un límite.
Una forma de gestionar el límite, cuando agregar más carriles ya no es opción, es controlar que la cantidad de peticiones nunca supere la capacidad del sistema. Hay dos alternativas principales. Rechazar el exceso de peticiones o encolarlas.
La primera alternativa, rechazar todas las peticiones que superen la capacidad disponible, es fácil de desarrollar, pero ofrece una experiencia de usuario mala y que además complica la situación. Lo que ve la persona es un mensaje “ahora no puedes, inténtalo más tarde”, que los lleva a repetir. Pensad cuántas veces una página web os falló y lo que habéis hecho es pulsar el botón de recargar. Ese reintento crea aún más peticiones y empeora la situación.
La segunda alternativa consiste en “dejar en espera” a las peticiones que superan la capacidad y hacerlas prosperar cuando una petición anterior se completa. Imaginad una ruta que tuviera un semáforo a su entrada que dejara pasar solo la cantidad de autos determinada. La ruta estaría fluida, pero tendrías que hacer cola para entrar. Llevado a una web, esta alternativa ofrece una mejor experiencia y, además, evita el efecto de los reintentos: nadie quiere salirse de la cola porque tendría que volver a hacerla desde el principio.
Este es el principio detrás de la solución que implementamos para el 1° de octubre. Creamos un sistema de turnos configurado para dejar pasar una cantidad fija de personas a la web por minuto (para vuestra curiosidad, varias decenas de miles cada minuto).
1-O. La tensa espera
Durante dos semanas de septiembre el equipo desarrolló e integró la solución. Las pruebas fueron satisfactorias, tocaba salir a producción.
Y ahí estábamos. 1 de octubre, 7.00 am, todo preparado, pero esta vez con nuestro sistema de colas listo. No voy a negar que había nervios, nadie quería arriesgar un vaticinio, en la memoria estaban las decepciones de meses anteriores.
Y llegaron las 10.00 y el tráfico en la web subió bruscamente. En 15 segundos la carga en el sistema se multiplicó y… ¡no pasó nada malo! Empezaron a asignarse turnos, nuestros sistemas estaban holgados, la web funcionaba perfectamente. El banco operó. Nuestros clientes, en la web y en el celu, tenían que esperar para acceder, sí, pero la operativa era fluida. Y la espera no era alta; no superó los 3 minutos.
La experiencia era muchísimo mejor que cualquier otro primer día. Es verdad que en redes sociales se vieron quejas por tener que esperar para acceder. Las encuestas de calidad que hacemos mostraron que, en general, la idea fue bien recibida y tuvimos la mejor valoración en un primer día hábil en mucho tiempo.
Habíamos logrado nuestro objetivo, habíamos estabilizado la situación.
Tech corner
Para los que tengan curiosidad técnica, lo que implementamos fue una cola de control de tráfico usando una variante de “leacking bucket”. Los tokens y las sesiones las manteníamos en un Redis, que nos daba el performance necesario. No necesitábamos persistencia, dado que la cola en sí es efímera y Redis es una gran tecnología para estos usos.
En nuestros debates para resolver el problema de la venta de dólares nos planteamos el buscar soluciones de elasticidad de cómputo para absorber el pico de demanda. No fuimos por ese camino porque nuestra arquitectura no lo soporta. El cuello de botella que encontrábamos estaba en el mainframe en sí. Los mainframe son unas tecnologías de alto desempeño y extremadamente robustas, pero no son tan elásticos como requería la situación.
El desarrollo y las pruebas fueron muy rápidas (en unos días lo teníamos listo). Lo hicimos sobre nuestra nueva arquitectura orientada a microservicios, basada en OpenShift. Además, ventajas de esa arquitectura, la solución es escalable y podemos integrarla en cualquier front-end en minutos.
Pensando en la experiencia del equipo de desarrollo interno, la solución auto provisiona colas de espera. Basta con llamar a la misma API con un nuevo “identificador único de cola” y ya se están generando turnos para esa nueva cola. Sobre una infraestructura elástica, es prácticamente automágico todo.
La gestión de la velocidad de vaciado del bucket fue completamente manual. Para más adelante implementaremos el loop de control enlazando al consumo de CPU. Y, hacia el futuro, estamos trabajando en poder descargar transacciones del mainframe, primero moviendo funcionalidad a la arquitectura de microservicios y luego yendo hacia cloud, pero eso es para otra nota….
El mejor problema
Es increíble cómo de un problema sale una solución brillante. La necesidad (solo teníamos 29 días para arreglar el problema), la diversidad (gente con mucha experiencia en el banco, pero también gente que se ha incorporado recientemente con experiencia en otras industrias), la tecnología (se ha trabajado mucho en tener una tecnología que permite desarrollos rápidos) y el trabajo en equipo nos permitieron llegar a buen puerto.
En ningún momento vimos la situación como una desgracia impuesta. Bien al contrario, el sentimiento generalizado era que “no había mejor problema en el que estar trabajando en tecnología en Argentina”. Y creo que esa fue la clave: nos pusimos un reto, teníamos un propósito muy concreto y ambicioso. Y lo superamos, trabajando en equipo, disfrutándolo.
Si te gustan los retos como este, te apasiona la tecnología, y quieres sumarte al equipo que está construyendo la plataforma financiera líder, ponte en contacto. ¡Siempre damos la bienvenida al talento!
Tu opinión enriquece este artículo: