Como fizemos a migração de cartões para a nossa infraestrutura?

Fizemos em abril o grande anúncio da migração da carteira de cartões da Máximo, a fintech peruana que agora utiliza nossa solução de emissão e processamento de cartões, Cards. Neste artigo, nós te apresentamos detalhes técnicos de como realizamos esse processamento crítico, algumas das ferramentas que utilizamos para continuar construindo toda a nossa infraestrutura da fintech e como nós integramos novos clientes de forma rápida e escalável na Pomelo. Vem com a gente!

O desafio da migração de cartões

O processo de migração de cartões e a transição do processamento de suas transações associadas são desafiadores sob diferentes perspectivas técnicas. Antes de nos concentrarmos em como nos preparamos para esse processo na Pomelo, vamos entender brevemente o que está envolvido nessa transferência:

• Em primeiro lugar, o novo emissor e processador de cartões, neste caso a Pomelo, precisa conhecer os dados do cartão anteriormente mantidos por outro emissor/processador – para que, no momento em que a bandeira (Visa ou Mastercard) começar a enviar transações para o novo processador, este possa autorizá-las e processá-las corretamente. Essa transferência de informações deve ser a mais rápida possível, pois o processamento de transações é interrompido durante a transferência, e esse tempo deve ser minimizado para afetar a atividade do titular do cartão pelo menor tempo possível.

• Em segundo lugar, a chegada de novas transferências e, portanto, um aumento no tráfego, coloca à prova a escalabilidade de nossa infraestrutura. Nossos serviços devem ser capazes de lidar com uma nova carga, novas comunicações… e, o que é mais importante, devem ser capazes de nos alertar rapidamente caso o processo não ocorra conforme o esperado – tornando o monitoramento uma função de vital importância. 

• E, por fim, as informações transferidas exigem um tratamento seguro, sendo as informações financeiras compatíveis com a certificação PCI-DSS. Isso impõe outros desafios nas comunicações que devemos levar em conta, dada a criticidade e a sensibilidade das informações.

Os pontos-chave para a migração:

A partir dessa análise, surgem os pontos mais importantes que a nossa solução deve enfatizar:

• Os tempos de processamento: parte do desempenho de nossa solução para transferir informações e evitar tempo de inatividade;
• A escalabilidade de nossa infraestrutura de emissão e processamento: tanto para o processamento da transferência de dados quanto para suportar a nova carga de transações;
• Segurança: particularmente na transferência e nas comunicações;
• Monitoramento: para poder detectar e corrigir qualquer imprevisto em qualquer estágio da migração.

Vejamos, ponto a ponto, como levamos em conta esses quatro pilares em nossa solução!

Transferência de informações do cartão

Como mencionamos, a transferência deve ocorrer no menor tempo possível, e por isso devemos manter o foco no desempenho e na ausência de tempo de inatividade. Para isso, projetamos uma solução específica, com uma arquitetura como a seguinte:

As informações dos cartões a serem migrados são tratadas por um componente que chamamos de Pomelo Card Migrator. Ele é responsável por interpretar um arquivo que contém as informações dos cartões a serem migrados, garantindo o processamento correto de todo o conjunto de cartões e, ao final, gerando um arquivo de saída (output) com os resultados da migração.

Esse componente executará chamadas para outros serviços internos, como os serviços do titular e do usuário do cartão, para garantir sua integridade e persistência. Ele também será executado com o objetivo de gerar arquivos de output – assim, realizando a maior parte do trabalho de I/O (input/output).

Como podemos otimizar esse comportamento? 

Na Pomelo, trabalhamos com uma stack de tecnologia diversificada, parte da qual é Kotlin, que aproveitamos ao máximo para esse componente. Seu tratamento de operações de I/O sem bloqueio, combinado com sua capacidade de desenvolvimento de operações simultâneas por meio de co-routines (rotinas concorrentes), nos permite ter um componente capaz de desempenhar uma tarefa complexa, como processar milhares de registros de cartões, fazer chamadas remotas, escrito de forma simples e eficiente, aproveitando toda a capacidade de processamento de nossos recursos. O conceito de concorrência estruturada, aliado ao tratamento reativo de flows, são ferramentas poderosas que o Kotlin oferece e que facilitam o uso e o desenvolvimento de nossos componentes.

Uso de filas de mensagens

Cada cartão é processado por meio da publicação e do consumo de mensagens, usando o AWS SQS (Simple Queue Service). Essa ideia simples de adiar e separar o processamento nos fornece recursos importantes:

1. Ela nos permite escalar horizontalmente o consumo para migração e persistência de cartões em nossa infraestrutura. Isso melhora substancialmente o desempenho, bastando adicionar uma nova instância. Embora essa escalabilidade possa ser automatizada, optamos, nesse caso, por manter o controle manual, conhecendo a carga ideal para nossos serviços;
2. Isso nos dá resiliência, porque sabemos que o processamento pode ser feito novamente no caso de possíveis erros, como por exemplo um erro de rede. Além disso, a incorporação de uma Dead Letter Queue nos dá a possibilidade de isolar casos de erro específicos, compreendê-los e poder resolvê-los rapidamente.

Para armazenar os resultados da migração, o uso de outro produto da AWS, o DynamoDB, contribuiu para a solução, considerando sua versatilidade, escalabilidade e capacidade de suportar grandes quantidades de escrita. Otimizamos nosso modelo, fazendo uso da técnica Single Table Design, tornando nossas consultas fáceis de escrever para gerar métricas e resultados.

Todas essas tecnologias se comunicam e colaboram para formar uma solução potente, sustentável e escalável.

Vamos dar uma olhada mais de perto nesse ponto abaixo!

Escalabilidade da nossa infraestrutura

Usando o Kubernetes, combinado com o componente KEDA e aproveitando o EKS da AWS, pudemos confirmar que nossas políticas de escalabilidade automática estavam funcionando corretamente. Esse foi um dos nossos primeiros marcos no planejamento e na execução da migração da Máximo.

Embora estivéssemos muito confiantes de que o Pomelo Card Migrator se dimensiona facilmente, graças ao seu design e também às ferramentas que usamos para configurá-lo, queríamos testá-lo e fizemos isso com vários testes de carga simulando dois tipos de tráfego:

• Para verificar a carga de migração, teste de spike foram os indicados.
• E para verificar se nossos serviços poderiam suportar o tráfego de um novo cliente, testes de carga tradicionais.

Para encontrar o número ideal de instâncias para o consumo de mensagens, equilibrando os custos, o desempenho e a integridade de nossos serviços, configuramos vários cenários: ter mais ou menos instâncias de consumo no Pomelo Card Migrator – variando até mesmo nossa concorrência interna e a configuração de recursos de nossas instâncias –, combinadas com diferentes estados de serviços de cartões e titulares de cartões.

Estes testes são uma parte fundamental de nosso desenvolvimento, especialmente devido à importância do processo de migração.

Se você quiser saber mais sobre esse tópico, este artigo no nosso blog explica tudo!

Protegendo o processo

Como a Pomelo é PCI-DSS Compliant, é nosso dever manter a segurança das informações. Utilizamos diversas tecnologias para atender a esse objetivo, entre as quais vale a pena destacar:

Para transferência de arquivos

O uso de criptografia assimétrica. Por exemplo, as transferências de arquivos entre a Pomelo e o Maximo – e todos os nossos clientes – são criptografadas usando o esquema PGP. O uso dessa técnica garante que somente a Pomelo possa ler as informações do cartão e do titular do cartão.

Para comunicações entre componentes

Ao usar a ferramenta Istio como service mesh, podemos estabelecer facilmente políticas de autorização, usando a funcionalidade Authorization Policies. É uma ferramenta fácil de usar que fornece uma camada de segurança eficaz que aproveitamos em nossa arquitetura para garantir que a comunicação entre nossos serviços seja segura.

Veja abaixo um exemplo de uma das configurações que aplicamos para entender como podemos tornar explícito o acesso a um endpoint do nosso serviço de cartão de forma 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"]

Essas duas não são as únicas ferramentas que usamos, pois manter os dados de cartões de pagamento seguros exige dedicação. Você pode saber mais sobre isso neste artigo sobre o uso da certificação PCI-DSS (em espanhol).

Sobre o monitoramento

Cada componente de nossa arquitetura é monitorado de diferentes maneiras, mas nossa ferramenta favorita que se mostrou fundamental para o sucesso da migração é a New Relic.

A rápida integração e a capacidade de criar dashboards e alertas, combinando informações de todos os componentes da solução, nos ajudam a ter uma visibilidade clara da integridade dos serviços e do processamento durante a execução da migração. E não apenas da migração de cartões, mas também do processamento de novas transações, que é uma parte fundamental da migração.

Além disso, a possibilidade de ter em um só lugar, por exemplo, as métricas do SQS, juntamente com o status do serviço e os resultados parciais da migração, simplifica substancialmente a tarefa de monitoramento e melhora nossa capacidade de reagir a métricas e alertas anormais.

Por exemplo, uma parte do nosso Dashboard, com foco no componente que descrevemos:

Embora a New Relic forneça ferramentas de monitoramento, também é útil combinar todas as informações e métricas que ela produz com as métricas de negócios: entender quais tipos de cartão foram migrados, juntamente com as transações e rejeições, nos dá visibilidade completa do processo de migração em tempo real. Por exemplo, a possibilidade de ver as métricas de rejeição dentro do contexto, em comparação com métricas gerais de rejeição, nos alerta sobre possíveis problemas na autorização de transações. Acreditamos que essa prática, que combina as duas fontes de dados, é um fator fundamental para a eficácia do nosso monitoramento e que procuramos seguir em todas as nossas funcionalidades.

**

Recapitulando, percorremos a implementação de ponta a ponta do nosso processo de migração, enfatizando diferentes aspectos essenciais e aprofundando conceitos técnicos que não se aplicam apenas ao nosso processo de migração, mas a qualquer componente da nossa infraestrutura. 

Esta é apenas uma parte de nossas tecnologias e práticas no desenvolvimento, monitoramento e escalonamento de nossa arquitetura para que seja robusta e segura em nível regional. A gente te convida a compartilhar e a discutir designs alternativos!

Se você possui cartões emitidos e está pensando em mudar de provedor, te convidamos a conhecer mais detalhes do processo na nossa documentação.