¿Cómo realizamos la migración de tarjetas hacia nuestra infraestructura?

Durante el mes de abril llevamos adelante el gran anuncio de la migración de la cartera de tarjetas de Máximo, la fintech peruana que ahora utiliza nuestra solución de emisión y procesamiento de Cards. En este artículo presentaremos detalles técnicos de cómo llevamos adelante este procesamiento crítico, algunas de las herramientas que usamos para seguir construyendo toda nuestra infraestructura fintech y cómo hacemos en Pomelo para integrar nuevos clientes de manera rápida y escalable. ¡Vamos!

El desafío de la migración de tarjetas

El proceso de migración de tarjetas y la transición del procesamiento de las transacciones asociadas a ellas es desafiante desde diferentes perspectivas técnicas. Antes de centrarnos en cómo preparamos este proceso desde Pomelo, entendamos brevemente qué implica esta transferencia:

• En primer lugar, se necesita que el nuevo emisor y procesador de tarjetas, en este caso Pomelo, conozca los datos de las tarjetas que anteriormente estaban en poder de otro emisor / procesador, de forma que en el momento que la red (Visa o Mastercard) comience a enviar transacciones al nuevo procesador, este pueda autorizarlas y procesarlas correctamente. Esta transferencia de información debe ser lo más rápida posible, ya que el procesamiento de transacciones se ve interrumpido durante el traspaso, y este tiempo debe ser minimizado para afectar la actividad de los tarjetahabientes por el menor tiempo posible.

• En segundo lugar, la llegada de las nuevas transferencias, y por ende, un aumento de tráfico, pone a prueba la escalabilidad de nuestra infraestructura. Nuestros servicios deben poder manejar una nueva carga, nuevas comunicaciones, y principalmente, deben poder alertarnos rápidamente en caso de que el proceso no salga de manera esperada, haciendo que el monitoreo adquiera un rol de vital importancia.
• Y por último, la información transferida requiere de un tratamiento seguro, siendo información financiera alcanzada por PCI-DSS. Esto impone más desafíos en las comunicaciones que debemos tener en cuenta dada la criticidad y sensibilidad de la información.

Las claves de la migración

A partir de este análisis, surgen los puntos más importantes sobre los que nuestra solución tiene que hacer énfasis:

• Los tiempos de procesamiento: parte de la performance de nuestra solución para transferir la información y evitar el downtime;
• La escalabilidad de nuestra infraestructura de emisión y procesamiento: tanto para el procesamiento de la transferencia de datos, como para soportar la nueva carga de transacciones;
• La seguridad: particularmente en la transferencia y en las comunicaciones;
• El monitoreo: para poder detectar y corregir cualquier imprevisto en cualquiera de las etapas de la migración;

¡Veamos punto a punto cómo tenemos en cuenta estos cuatro pilares en nuestra solución!

Transfiriendo la información de las tarjetas

Como mencionamos, la transferencia debe suceder en el menor tiempo posible, por lo que debemos mantener como foco la performance y no tener downtime. Para esto, diseñamos una solución específica, con una arquitectura como la siguiente:

La información de las tarjetas a migrar es manejada por un componente al que llamamos Pomelo Card Migrator. Este tiene la responsabilidad de interpretar un archivo que contiene la información de las tarjetas a migrar, garantizar el procesamiento correcto de todo el conjunto de tarjetas y finalmente generar un archivo de output con los resultados de la migración.

Este componente ejecutará llamadas a otros servicios internos, como los servicios de usuarios tarjetahabientes y tarjetas, para garantizar su integridad y persistencia. Además se ejecutará con el objetivo de generar archivos de resultados, haciendo entonces un trabajo mayormente de I/O.

¿Cómo podemos ser óptimos con este comportamiento? 

En Pomelo, trabajamos con un stack tecnológico diverso, parte del cual es Kotlin, el cual aprovechamos al máximo para este componente. Su manejo de operaciones I/O no bloqueantes, combinado con su capacidad para el desarrollo de operaciones concurrentes mediante corrutinas, nos permite tener un componente con una tarea compleja, como lo es procesar miles de registros de tarjetas, haciendo llamadas remotas, escrito de manera simple y performante, aprovechando toda la capacidad de procesamiento de nuestros recursos. El concepto de concurrencia estructurada, sumado al manejo reactivo de los flows, son herramientas poderosas que Kotlin provee, que nos facilitan el uso y el desarrollo de nuestros componentes.

Haciendo uso de las colas de mensajes

Cada tarjeta que se procesa, se realiza mediante la publicación y el consumo de mensajes, utilizando AWS SQS. Esta idea sencilla, de diferir y separar el procesamiento, nos da características claves:

1. Nos permite escalar horizontalmente el consumo para la migración de tarjetas y la persistencia en nuestra infraestructura. Esto mejora sustancialmente la performance, solamente sumando una nueva instancia. Si bien esta escalabilidad puede automatizarse, optamos en este caso por mantener el control manual, conociendo la carga óptima para nuestros servicios;
   
2. Nos otorga resiliencia, a sabiendas de que el procesamiento puede reintentarse ante potenciales errores como podría ser un error de networking. Y además, la incorporación de una Dead Letter Queue, nos da la posibilidad de aislar casos erróneos particulares, entenderlos, y poder solucionarlos rápidamente.

Para almacenar los resultados de la migración, el uso de otro producto de AWS, DynamoDB, contribuyó a la solución, teniendo en cuenta su versatilidad, escalabilidad y su capacidad de soportar grandes cantidades de escritura. Optimizamos nuestro modelo, haciendo uso de la técnica de Single Table Design, haciendo que nuestras queries sean sencillas de escribir para generar métricas y resultados.

Todos estas tecnologías se comunican y colaboran para conformar una solución potente, mantenible y escalable. ¡Profundizamos en este punto a continuación!

La escalabilidad de nuestra infraestructura

Gracias al uso de Kubernetes, combinado con KEDA y aprovechando EKS de AWS, pudimos confirmar que nuestras políticas de escalabilidad automática funcionaban correctamente. Este fue uno de nuestros primeros hitos a la hora de planificar y ejecutar la migración de Máximo.

Si bien teníamos mucha seguridad en que el Pomelo Card Migrator escala con facilidad, gracias a su diseño y también a las herramientas que utilizamos para configurarlo, queríamos ponerlo a prueba y lo hicimos con diversas pruebas de carga simulando dos tipos de tráfico:

• la carga de la migración, las pruebas de spike fueron las indicadas
• y para verificar que nuestros servicios podrían soportar el tráfico de un nuevo cliente, pruebas de carga tradicionales.

Para encontrar la cantidad de instancias óptimas para el consumo de los mensajes, equilibrando costos, performance y la salud de nuestros servicios, establecimos diversos escenarios: teniendo más o menos instancias consumidoras en Pomelo Card Migrator – incluso variando nuestra configuración de concurrencia interna y recursos de nuestras instancias -, combinando con diferentes estados de los servicios de tarjetahabientes y tarjetas. 

Hacer este tipo de pruebas es una parte fundamental de nuestro desarrollo, más aún teniendo en cuenta la importancia del proceso de migración.

Si querés saber más sobre este tema, ¡en este artículo del blog te contamos todo!

Securizando el proceso

Siendo Pomelo PCI-DSS Compliant, es nuestro deber mantener la seguridad de la información. Utilizamos varias tecnologías para cumplir con este objetivo, entre las cuales vale la pena resaltar:

Para la transferencia de archivos

El uso de criptografía asimétrica. Por ejemplo, las transferencias de archivos entre Pomelo y Máximo – y todos nuestros clientes – se cifran mediante el esquema PGP. El uso de esta técnica nos garantiza que únicamente Pomelo es quien podrá leer la información de las tarjetas y los tarjetahabientes.

Para las comunicaciones entre componentes

Gracias al uso de la herramienta Istio como service mesh, podemos establecer fácilmente políticas de autorización, usando la funcionalidad de Authorization Policies. Es una herramienta fácil de utilizar, que otorga una capa de seguridad efectiva que aprovechamos en nuestra arquitectura para garantizar que la comunicación entre nuestros servicios sea segura.

Debajo, un ejemplo de como se ve una de las configuraciones que aplicamos, para comprender cómo podemos explicitar el acceso a un endpoint de nuestro servicio de tarjetas de manera declarativa:

name: cards-issuing-service-name
namespace: issuing-and-processing-namespace

AuthorizationPolicy:
  - name: deny-everything-but-migrator-service
    action: DENY
    rules:
      - from:
        - source:
            notPrincipals:
              - "cluster.local/ns/cluster-name/sa/migrator-service"
        to:
          - operation:
              methods: ["POST"]
              paths: ["/v1"]

Estas dos no son las únicas herramientas que utilizamos, ya que mantener seguros los datos de tarjetas de pago requiere de dedicación. Puedes conocer más sobre eso en nuestro artículo acerca de la certificación PCI-DSS.

Sobre el monitoreo

Cada componente de nuestra arquitectura es monitoreado de diferentes maneras, pero nuestra herramienta favorita y que resultó clave para el éxito de la migración, es New Relic.

La integración rápida y la capacidad de construir dashboards y alertas, combinando la información de todos los componentes de la solución, nos ayuda a tener clara visibilidad de la salud de los servicios y el procesamiento durante la ejecución de la migración. Y no solamente de la migración de tarjetas, sino también del procesamiento de las nuevas transacciones, arista fundamental de la migración. 

Además de eso, la posibilidad de tener en un mismo lugar, por ejemplo, métricas de SQS, junto con el estado de los servicios y los resultados parciales de la migración, simplifica sustancialmente la tarea de monitoreo y mejora nuestra capacidad de reaccionar ante métricas anormales y alertas.

Por ejemplo, una parte de nuestro dashboard, focalizado en el componente que describimos:

Si bien New Relic provee herramientas de monitoreo, también es de utilidad combinar toda la información y métricas que produce, con métricas de negocio: entender qué tipos de tarjetas se migraron, junto con las transacciones y rechazos, nos da una visibilidad completa del proceso de migración en vivo. Por ejemplo, poder ver métricas de rechazos, comparando con métricas de rechazos generales, nos alerta acerca de posibles problemas a la hora de autorizar transacciones. Creemos que esta práctica, que combina ambas fuentes de datos, es un factor clave de nuestra eficacia al monitorear, y una que buscamos seguir en todas nuestras funcionalidades.

Recapitulando, recorrimos la implementación punta a punta de nuestro proceso de migración, haciendo énfasis en distintos aspectos esenciales y adentrándonos en conceptos técnicos que no sólo aplican a nuestro proceso de migración, sino a cualquier componente de nuestra infraestructura.

Esto es solamente una parte de nuestras tecnologías y prácticas a la hora de desarrollar, monitorear y escalar nuestra arquitectura para que sea robusta y segura a nivel regional. ¡Te invitamos a compartir y debatir sobre otros diseños alternativos!

Si tienes tarjetas emitidas y estás pensando en cambiar de proveedor, te invitamos a conocer más detalles del proceso en nuestra documentación.