Mercator: un mapa para navegar los errores de terceros
Cuando 2 + 2 no siempre es 4
En computación, los problemas suelen ser deterministas: si sigues los mismos pasos deberías recibir siempre el mismo resultado.
Pero no siempre es así, especialmente cuando se trabaja con integraciones de terceros o sistemas distribuidos. Estos sistemas no siempre responden de forma predecible. Pueden generar errores, tiempos de espera o datos ambiguos que rompen esa lógica determinista.
El desafío de los “unknowns”
En Fintoc, conectamos comercios y bancos para procesar pagos de manera eficiente y confiable. Lo hacemos con integraciones que envían y reciben información sobre transacciones en tiempo real. Pero al trabajar con terceros, surgen errores que no siempre podemos clasificar fácilmente.
A estos errores los llamamos unknown errors o unknowns. Son como cuando tu internet se cae y no sabes si el problema está en el router, el cable o el proveedor. Aunque representan solo el 0,1% de los pagos, resolverlos era un proceso lento y manual. Implicaba revisar logs, explorar la integración, identificar el problema en el código, corregirlo, subir un PR, aprobarlo y desplegarlo. Todo esto podía tomar hasta medio día.
Este esfuerzo desviaba a los devs de sus prioridades y afectaba la experiencia de los usuarios, algo que iba en contra de nuestra misión de simplificar los pagos. Por eso, necesitábamos una solución.
Mercator: el mapa
Decidimos cambiar la estrategia y movimos la responsabilidad de procesar errores desde la integración hacia Rails, el sistema que orquesta y administra gran parte de la lógica y el flujo de datos dentro de Fintoc. Esto nos dio visibilidad sobre los patrones: qué integraciones generaban más problemas, cuáles eran los más comunes y cómo optimizar nuestro sistema.
Así nació Mercator. Una herramienta dinámica para “mapear” errores en pagos, inspirada en el cartógrafo Gerardus Mercator, quien creó un mapa que revolucionó la navegación. Como él, buscamos convertir la incertidumbre en patrones claros y manejables.
.png)
¿Qué estamos mapeando?
Muchos errores provienen de respuestas ambiguas o comportamientos inconsistentes en las integraciones bancarias. Estos errores incluyen datos mal formateados, respuestas ambiguas, entre otros.
Por ejemplo:
- Errores de formato: Campos incompletos o datos inválidos enviados al banco.
- Problemas de conexión: Fallos temporales en las redes bancarias.
- Respuestas ambiguas: Mensajes de error poco claros que no ofrecen suficiente información.
La clave para mapearlos está en reconocer patrones repetitivos que nos ayuden a clasificarlos y tratarlos de manera eficiente. Faltaba definir el cómo.
La solución: Regex
Había varias formas de mapear, desde herramientas tradicionales hasta inteligencia artificial. Decidimos partir con algo simple, iterar rápido y probar la solución antes de hacer una inversión mayor. Optamos por usar regex — expresiones regulares — porque nos ofrecían bastante control y la flexibilidad necesaria para adaptarnos rápidamente a las diferentes respuestas de los sistemas bancarios.
Así, identificamos errores recurrentes y los empezamos a clasificar:
Estos patrones regex fueron el punto de partida para estructurar los unknowns. Con esto, desarrollamos un flujo práctico que permite procesar los errores de forma automática y adaptativa.
¿Cómo se ve en la práctica?
Cuando un cliente inicia un pago y ocurre un unknown (que pasa en el 0,1% de los casos), el flujo funciona así:
- Errores conocidos: Si el error ya tiene un patrón definido, se clasifica automáticamente y se notifica al cliente con la información correspondiente.
- Errores desconocidos: Si el error no está mapeado, el sistema lo registra y alerta al equipo de operaciones. Ellos crean un nuevo patrón, lo ingresan al sistema y la clasificación se actualiza en minutos.
.gif)
De cara al usuario, si recibe un error desconocido, el widget (la ventana que muestra al usuario el estado de su transacción) inicialmente muestra un mensaje genérico.
Una vez que se crea el patrón correspondiente, el cliente recibe un mensaje claro con la razón específica del problema, como: 'Clave PIN inválida’.
De manual a dinámico
Antes de Mercator, cualquier cambio para procesar o categorizar errores requería actualizar el código de forma manual. Esto implicaba:
- Identificar un patrón nuevo de error en los logs.
- Modificar el código para manejar ese error (por ejemplo, añadir una nueva condición o regla).
- Crear un PR (Pull Request) con los cambios en el código.
- Esperar revisión, aprobación y desplegar los cambios al sistema.
Este proceso podía tomar horas. Con Mercator, la categorización se hace dinámica y adaptable, eliminando la necesidad de este flujo complicado y permitiendo que el sistema aprenda de los errores sin intervención manual inmediata.
En las últimas dos semanas, logramos categorizar ~130k errores en más de 100 categorías, haciendo que sean más descriptivos y permitiendo una respuesta más rápida y eficiente para resolverlos.
El futuro de Mercator
Mercator no se acaba acá. Cada nuevo error que aparece se analiza, categoriza y prioriza para buscar patrones y encontrar soluciones que hagan el producto mejor.
El próximo paso es incorporar patrones predictivos basados en datos históricos para no solo reaccionar ante errores, sino también anticiparlos y evitarlos antes de que ocurran.
No te pierdas los próximos eventos y blogs de ingeniería, ¡inscríbete aquí!
.gif)
.gif)
.gif)
