El viaje de la Fintech D24 hacia la construcción de un sistema de observabilidad de pagos.

En D24 somos un proveedor de servicios de pagos mundial y uno de los más grandes de América Latina. Gracias a nuestros distintos proveedores, tenemos integraciones con cientos de bancos, billeteras, adquirentes de tarjetas y otras entidades locales, a través de una única interfaz de programación de aplicaciones (API) y sin cargas operativas. Procesamos millones de transacciones todos los días de usuarios que buscan (i) depositar o retirar fondos hacia o desde sitios web de comerciantes o (ii) comprar productos o servicios en línea de nuestros comerciantes. Esa es la razón por la cual nuestros servicios deben estar disponibles a toda hora, los 365 días del año. Para conseguir esa disponibilidad, debemos entender a fondo y en todo momento lo que no se ve a simple vista, pero sucede bajo la superficie. Y por eso nos aliamos con New Relic, para poder comprender mejor nuestro stack tecnológico, descubrir las tendencias emergentes y enfrentar los problemas antes de que afecten a nuestros clientes. Nos enorgullece poder mantener un SLA que excede el 99.99% gracias a la capacidad de New Relic de combinar las métricas operacionales con infraestructura y APM. No solo nos mantenemos al tanto de cómo están rindiendo nuestros sistemas, sino que también sabemos cómo se están usando y qué es lo que no funciona como debería.

Recibir un código HTTP 200 en menos de 300 milisegundos después de crear una solicitud de depósito no necesariamente es sinónimo de que todo marcha sobre ruedas. En cambio, comprobar que los usuarios finales pueden pagar sin la más mínima dificultad sí indica que todo anda bien. Para ello, necesitamos poder registrar y rastrear cada intento de pago en cada método de pago que ofrecemos, investigar a fondo cada anomalía antes de que se convierta en un problema e implementar una solución antes de que los clientes siquiera se percaten del impacto en nuestras operaciones. Debido al inmenso tráfico que circula por nuestros sistemas, necesitamos poder responder muchas preguntas en segundos, no horas. ¿Están fallando los pagos porque se ha caído el sitio web del banco local o acaso nuestros servidores están sobrecargados? ¿Se están ejecutando las consultas de la base de datos como de costumbre o está uno de nuestros despliegues canary ejecutando consultas sin la indexación apropiada? ¿Se rechazó un pago por causa de una regla antifraude prevista o por una configuración mal hecha?

Confiamos en las funciones de observabilidad de New Relic para crear un sistema de observabilidad de pagos mundial e ininterrumpido. En particular, sacamos provecho de las siguientes funciones clave que las herramientas de New Relic hacen posible: dashboards, eventos personalizados, métricas de despliegue canary, sistemas de alerta integrados, logs y rastreo infinito.

Los eventos personalizados nos ayudan a investigar cuando las cosas salen mal

Los eventos personalizados de New Relic son una herramienta primordial de la cual dependemos. Nos han abierto un potencial inmenso gracias a las grandes posibilidades que ofrece el lenguaje de consultas de New Relic (NRQL). 

Cada vez que un comerciante crea una nueva transacción —una nueva solicitud de depósito o retiro—, nuestros microservicios envían a New Relic un evento personalizado en tiempo real con los detalles. ¿Creó un comerciante una solicitud de depósito? Recibimos un evento de tipo "CREATE". ¿Hizo efectiva un usuario la solicitud de depósito? Recibimos otro evento de tipo "COMPLETE". ¿Estamos recibiendo una cantidad adecuada de eventos completados en comparación con la cantidad de pagos creados en los últimos minutos? Entonces todo anda bien. ¿Estamos por debajo de un umbral predefinido? Debemos investigar qué anda mal. ¿Están creando los usuarios más solicitudes de depósito por minuto? Lo más probable es que esto signifique que no pueden pagar y están tratando de hacerlo varias veces. ¿Permanecen todas las métricas iguales aparte de la tasa de conversión? Lo más seguro es que haya demoras en la emisión de las transacciones por parte del banco.

Tomemos a Pix de ejemplo. Pix es un método de pago diseñado por el Banco Central de Brasil para realizar transferencias bancarias a los 10 segundos de que pague el usuario. Los usuarios finales lo pueden usar gratis y lo único que necesitan es una cuenta bancaria en una institución financiera brasileña. El Banco Central de Brasil requiere que todos los bancos locales estén integrados con Pix y que ofrezcan determinados contratos de nivel de servicio (SLA). Ahora bien, los usuarios finales utilizan decenas de bancos importantes. Y cualquiera de esos bancos puede sufrir problemas en un momento dado. Cuando eso ocurre y alguno de estos bancos tiene problemas ajenos a nuestro control, ¿cómo podemos saberlo? Aunque no podamos corregir el problema porque la causa sea la institución local, tenemos que saber que existe para informar a los comerciantes en tiempo real de modo que puedan tomar las medidas necesarias.

Por eso hemos creado dashboards que nos permiten ver en tiempo real el rendimiento de cada banco. Si se dan anomalías, podemos investigar más a fondo observando las métricas de los usuarios de esa institución financiera en particular; métricas como el índice de conversión, el tiempo de aprobación promedio y la cantidad de depósitos por usuario. Analizar estas métricas nos permite comprender dónde radica el problema. ¿Se debe al banco receptor ¿Cambiar el banco receptor (el que se le pide a los usuarios que envíen el dinero) ayudaría? ¿O la culpa es del banco que envía el dinero (aquel de donde se reciben los fondos)? Esta capacidad que nos ofrece New Relic va más allá de una simple observabilidad técnica, ya que fomenta una mayor transparencia en relación a las operaciones del negocio en general.

Dashboards para índices de conversión

Antes de comenzar a usar New Relic hace algunos años, dependíamos de las métricas de nuestro proveedor de servicios en la nube para comprender el estado de nuestra infraestructura y nuestras plataformas de inteligencia empresarial con la idea de hacer seguimiento a los KPI de negocio. Pero a medida que fuimos ganando clientes en todo el mundo y llegamos a nuevos mercados, comprendimos que teníamos que transformar toda la información que teníamos en algo verdaderamente práctico.

Una de las áreas fundamentales que nos interesa monitorear es la tasa de conversión de todos nuestros métodos de pago. Como somos un proveedor de servicios de pago, estamos integrados con cientos de proveedores externos que pueden ser billeteras digitales, bancos locales o adquirentes de tarjetas. Cuando estamos tratando con cualquiera de nuestros comerciantes, si uno de estos proveedores tiene problemas es como si los tuviéramos nosotros.

Por eso hemos creado los dashboards de New Relic, que nos permiten revisar el rendimiento de cada método de pago de manera separada en casillas. Gracias a la capacidad de NRQL, cada mosaico resume el flujo de los pagos que se están creando y de aquellos que se están completando en tiempo real (y, por lo tanto, la tasa de conversión). Una métrica clave para nuestro negocio es la tasa de conversión de nuestros métodos de pago, que muestra si un método de pago ofrece o no la experiencia del usuario que nosotros deseamos. Si una tasa de conversión cae por debajo de los umbrales aceptables, nuestro equipo de monitoreo recibe alertas que nos permiten actuar de inmediato (por ejemplo, activando una solución de respaldo mientras investigamos qué pasa con el proveedor). También comparamos, en las mismas casillas, los resultados en tiempo real con los resultados del momento equivalente la semana anterior, lo que nos permite detectar automáticamente anomalías propias de una temporada.

Estos dashboards tienen tablas con los nombres y las métricas para cada uno de nuestros comerciantes. Si sospechamos que los problemas suceden solamente con determinados comerciantes, podemos hacer clic en el nombre que corresponde y así filtrar automáticamente todas las casillas de la página en función de las métricas del comerciante en cuestión. Y si queremos profundizar en las métricas relativas a un método de pago y un comerciante en particular, solo con hacer clic en el método de pago ya se abre otra página con más métricas. Cuando detectamos una anomalía, es increíble con qué rapidez descubrimos por qué sucede.

Alertas integradas

Por muy bueno que sea contar con todas las métricas que afectan nuestro negocio, hay tantos servicios, servidores, bases de datos, métodos de pago y comerciantes que no es posible monitorearlo todo manualmente desde un mismo dashboard. Por este motivo, cada una de las métricas importantes para nosotros cuenta con sus alertas respectivas. New Relic nos permite programar alertas sencillas capaces de enviarnos notificaciones para todos nuestros comerciantes, métodos de pago y las métricas de infraestructura sin ninguna complicación.

Todas nuestras alertas se envían a través de Slack. Contamos con un buen número de grupos de Slack, cada uno de ellos dedicado a algún tipo de monitoreo. Recibimos alertas siempre que observamos un síntoma de rendimiento deficiente: cuando las tasas de conversión son más bajas de lo que se esperaba, cuando las métricas de infraestructura están acercándose a ciertos valores o cuando los comerciantes dejan de enviar tráfico para que podamos ofrecerles algún tipo de asistencia en caso de que estén teniendo problemas internos, por ejemplo. Nos complace poder aprovechar nuestra experiencia y desarrollar prácticas de observabilidad para asegurarnos de que nuestros comerciantes también obtengan los resultados esperados.

Métricas de despliegue canary y rastreo infinito

El año pasado, trabajamos arduamente para migrar nuestros microservicios a Kubernetes con la intención de escalar rápida y automáticamente. Nuestros sistemas tenían que ser capaces de crecer tan rápido como nuestra empresa. Para lograr este objetivo, optamos por una estrategia lenta y segura que nos garantizara que el proceso de pago del usuario no se vería afectado. En la primera etapa de la migración, los nuevos servicios de Kubernetes recibirían un porcentaje muy pequeño del tráfico con el fin de asegurarnos de que todas las métricas de APM fueran las mismas o incluso mejores. Luego fuimos aumentando el tráfico de manera progresiva hasta que pudimos cerrar por completo los servicios heredados. Logramos medir y optimizar nuestra capacidad de escalar dinámicamente en función del tráfico que recibe nuestra plataforma. 

Ahora podemos atender miles de transacciones por segundo (TPS) y nuestra factura de infraestructura ha permanecido estable con el paso del tiempo. 

A medida que continuamos creciendo, seguimos adaptándonos a las necesidades de nuestros comerciantes, lo que significa tener la capacidad de implementar cambios rápidamente y sin efectos negativos. Necesitábamos poder asegurarnos de que desplegar una nueva versión de una aplicación no supondría ningún riesgo. Pero, naturalmente, cuantos más despliegues se hacen, mayor es el riesgo de introducir comportamientos indeseados.

Ahora, incluso después de que la nueva versión ha superado todas las validaciones anteriores referentes a las pruebas y la calidad del código, podemos monitorear en tiempo real cualquier variación de las métricas clave de la aplicación, para lo cual enviamos a New Relic una notificación acerca del despliegue de una aplicación específica a través del método de despliegue canary.

Con un stack de herramientas de código abierto como ArgoCD, ArgoRollout y GitOps Methodologies, todo despliegue nuevo comienza a recibir el 1% de tráfico o incluso menos para las aplicaciones más críticas. Luego configuramos consultas para métricas, como la tasa de errores, usando NRQL; cuando el monitoreo muestra que la infraestructura es sólida —con una tasa de errores y otras consultas dentro de los valores esperados—, Argo aumenta automáticamente el tráfico al nuevo despliegue y luego lo vuelve a medir. El proceso continúa hasta que el nuevo despliegue administra todo el tráfico. La integración con herramientas de CI/CD como Argo nos permite tener más control sobre los despliegues y avanzar a buen ritmo hacia nuestro objetivo de facilitar entregas continuas.

Estas metodologías de observabilidad y organizacionales nos han permitido mejorar el tiempo medio de recuperación (MTTR) en un 90%: nos toma menos de 5 minutos identificar un problema. Ahora, cuando detectamos cualquier tipo de incidencia, no es porque los comerciantes nos están advirtiendo de que (por ejemplo) los pagos no se están efectuando, sino porque aplicamos una estrategia proactiva y la usamos, a su vez, para informar a nuestros comerciantes del impacto del problema existente para que puedan tomar las medidas necesarias y ayudar a los usuarios finales a tener la mejor experiencia posible. Hemos diseñado un sistema de observabilidad escalable que nos ha dado un tiempo de actividad de más del 99.99% sin que haya fricción en nuestras prácticas de innovación continua.

Lee más historias de clientes.