Transfers: O desafio de uma jornada de transferência modularizada na nuvem

Artigo escrito por Yuri Francisco e Nattan Lucena

 

Nosso desafio

Uma das missões da Dock é promover a inclusão financeira. Facilitamos o acesso a novos produtos e features, de maneira fácil e descomplicada, para que todas as pessoas possam ter acesso a serviços financeiros. Resultado disso são os mais diversos serviços bancários de transferência de dinheiro de uma conta de origem para uma conta de destino, tanto internamente em nossa estrutura, quanto para outras instituições financeiras. TEFs, TEDs, CNABs, Pix, Remessas internacionais e todos os demais serviços que disponibilizamos para nossos clientes, numa base de mais de 61,5 milhões de contas ativas.

Desde o início da construção do BaaS (Banking as a Service), todos esses serviços foram criados utilizando arquitetura de microsserviços, cada um com sua stack própria, integrações e resiliências específicas, determinadas pela necessidade de cada produto. 

Estamos num cenário onde temos um amplo espaço para pensarmos em novos produtos e repensarmos os já existentes. Levamos a sério nosso lema “we dare the impossible”, sempre pensando na evolução do mercado financeiro e como podemos ter diferenciais que impactem positivamente as vidas de nossos clientes.

 

O problema

Quando falamos de transações financeiras, é essencial que toda transação ocorra de maneira segura, rápida e confiável. A Dock, desde o seu surgimento, possui um serviço de transferências bancárias baseado em arquivos CNAB, que é um padrão de formatação de arquivos adotado por grandes instituições financeiras do Brasil e que foi definido pela FEBRABAN. O modelo é amplamente utilizado no mercado e se tornou um padrão para envio e recebimento de transações financeiras em lote. O serviço atual construído para a realização de transferências baseia-se no seguinte modelo:

Embora funcional, ao trabalharmos com transações em lote via arquivo, necessitamos da integração com algum parceiro para transmissão dessas transações (arquivo) até as instituições financeiras que realizam o processamento dos dados e realizam as transferências até as contas destino. Ao incluir um intermediário no processamento, abrimos brecha para falhas em todo o processo de transferência pois, por um determinado período de tempo, o controle sobre o fluxo transacional não estará disponível e a Dock acaba por “delegar” esse processamento a um ente externo, tendo o ônus operacional de lidar com possíveis chamados em caso de atraso dos créditos ou de devoluções não efetivadas.

Se isso já não fosse o bastante, ao trabalharmos com os arquivos CNAB, dependemos de “janelas de operação” para processamento das transações, ou seja, temos faixas de horários pré-determinadas para realizar a transmissão dos arquivos através da empresa parceira. Ao enviar um arquivo fora da “grade de horário”, ele é automaticamente recusado e todas as transações presentes nele precisam ser agendadas para novo envio ou devolvidas. Veja as janelas a seguir: 

• 09:00 – Processar todos os pedidos das 15:01 (D-1) às 09:00 (D+0);
• 10:00 – Processar todos os pedidos das 09:01 (D+0) às 10:00 (D+0);
• 11:00 – Processar todos os pedidos das 10:01 (D+0) às 11:00 (D+0);
• 12:00 – Processar todas as solicitações das 11:01 (D+0) às 12:00 (D+0);
• 13:00 – Processar todas as solicitações das 12:01 (D+0) às 13:00 (D+0);
• 14:00 – Processar todos os pedidos das 13:01 (D+0) às 14:00 (D+0);
• 15:00 – Processar todas as solicitações das 14:01 (D+0) às 15:00 (D+0).

O fato de existir uma janela de operação não é necessariamente ruim, pois na verdade usamos como base o mesmo horário da grade utilizada pelo SPB. O que torna essa orquestração pouco performática é o fato de que, ao enviar uma transação, não temos como determinar com exatidão o tempo de resposta de processamento, ou seja, não temos como saber ao certo quando um “arquivo de retorno” será recepcionado e processado em nossa infra, de modo a atualizarmos as transações que foram enviadas anteriormente.
Olhando por outro ângulo, pensando na jornada do usuário, a experiência provida não é das melhores pois condicionamos a execução de uma operação a um contexto de grade de horário, onde o tempo médio de processamento de uma transação ultrapassa 2 horas, de acordo com dados que temos aqui.

 

A ideia

Criar um hub de transferências onde a partir de único ponto de entrada fosse possível efetuar transferências de ativos para múltiplos destinos diferentes através de provedores de serviço especializados. Foi partindo desse pressuposto que iniciamos o esboço de um produto que atendesse essa necessidade.

Aqui na Dock temos uma máxima de “colocar as aplicações para trabalharem para a gente, e não o contrário”. A solução atual de transferência, por conta de seu modelo de implementação, tinha vários “pontos de ruptura”, ou circuit breakers na infraestrutura, ou seja, pontos da orquestração onde era necessário atuar manualmente em caso de falha, como quando um arquivo de retorno não era tratado corretamente ou quando uma chamada a um ente externo apresentava erro de timeout sem que houvesse possibilidade de retentativa.

A partir dessas dores cotidianas, chegamos a um esboço de arquitetura onde conseguimos mitigar quase que integralmente todos os circuit breakers. E como fazemos isso então? Simples, adotando boas práticas de arquitetura e desenvolvimento de software. Começamos por definir uma abordagem do tipo “dividir e conquistar”, ou seja, separar as responsabilidades, isolar os componentes e abstrair toda regra de negócio para fora da API de entrada, deixando-a leve, responsiva e com o mínimo de responsabilidade.

A essa altura, já havíamos percebido que todas essas conjecturas nos conduziram a um modelo de processamento assíncrono de transações, o que em um contexto transacional é ótimo pois nos garante maior controle sobre toda a esteira de processamento de uma transferência, podendo trabalhar individualmente em cada componente da esteira isoladamente, com monitoria e resiliência. Nossa ideia era nunca mais ficar “às cegas” e ter total controle sobre nossa operação do ponto de vista sistêmico.

A solução

Para dar vida a todos as ideias que tivemos, optamos por utilizar uma arquitetura descentralizada, com módulos independentes e distribuídos, favorecendo o desacoplamento entre os componentes e garantindo escalabilidade, monitoria e resiliência.

A porta de entrada para o produto é a API, que tem como responsabilidade receber os pedidos de transferência, validar configurações e encaminhar para processamento assíncrono. O padrão de arquitetura escolhido foi o Clean Architecture. O padrão de arquitetura limpa nos viabiliza desenvolver uma aplicação altamente testável, agnóstica do ponto-de-vista de persistência de dados, com baixo acoplamento entre as camadas e isolamento das regras de negócio. Sendo o entry point do produto, a API tem que ser altamente escalável, performática e de fácil manutenção, garantindo o ciclo de evolução do produto composto de melhorias, correções e novas funcionalidades.

Na visão do core, optamos por utilizar uma arquitetura baseada em eventos, utilizando os serviços de tópico (Simple Notification Service – SNS) e fila (Simple Queue Service – SQS) da AWS para processamento assíncrono das transações. A opção pela postagem de eventos no tópico do core mitigou questões de dual writing, pois uma mesma mensagem postada pode ser consumida por múltiplos consumidores de maneira paralela, otimizando o tempo de processamento e assegurando mais uma vez o desacoplamento entre os componentes.

Aliada a essa visão de processamento assíncrono, adicionamos a possibilidade de Scheduling de transações baseado no calendário contábil da FEBRABAN, outros calendários ou via solicitação do próprio cliente através do campo schedulingDate disponível no payload de entrada da aplicação.

Por fim temos os providers modules que são os componentes responsáveis por abstrair todo padrão de mensageria e comunicação entre a Dock e as empresas parceiras, tais como instituições financeiras, provedores de serviços de tecnologia e órgãos regulatórios. Ao isolarmos essa camada de integração com os entes externos, visamos facilitar a manutenção, escalabilidade e evolução desses serviços, fazendo com que as regras de negócios internas da Dock permanecessem isoladas das regras de negócios específicas de cada parceiro de integração.

 

O resultado

Conforme esperado, ao deixarmos de utilizar um modelo baseado em arquivos em prol de um modelo Near Real Time, reduzimos drasticamente o tempo de processamento de uma transação de transferência, partindo de uma média de 160 minutos na solução atual para 18 minutos no Transfers. Esse tempo leva em consideração toda orquestração síncrona e assíncrona do produto, desde a recepção da mensagem em nossa API, validações de anti-fraude, operações em conta e resposta do banco destino.

 

 

A depender do modelo de transferência escolhido pelo cliente (o produto dispõe de 5 modalidades de transferência atualmente), o tempo total para a liquidação de uma transferência entre bancos pode ser de menos de 5 minutos. Utilizando uma integração direta com o Sistema de Pagamentos Brasileiro – SPB (em desenvolvimento) será possível reduzir ainda mais esse tempo.

De maneira gradativa os clientes da base atual estão sendo migrados para o novo produto, e temos visto um interesse muito grande por parte de novos clientes e parceiros na utilização da nova plataforma de transferências.

Quanto ao tempo de resposta da API, usando um código similar ao do produto atual (requisitos funcionais já atendiam ao negócio), porém, com alteração da arquitetura, reduzimos pela metade o tempo médio de processamento de uma requisição no endpoint que processa as transferências.

 

 

Entendemos que em um contexto de expansão internacional como o que a Dock está enfrentando, o Transfers será uma peça fundamental na concretização deste objetivo, pois oferece um produto robusto, confiável, escalável e de fácil parametrização quando se trata de transferências de ativos. Ao todo o produto já transacionou mais de R$ 18 milhões de reais em ativos e esse número segue em constante crescimento.

 

Como a AWS nos ajudou nessa jornada?

Sabe-se que a computação em nuvem tornou mais simples e robusta a manutenção de sistemas complexos e de missão crítica, uma vez que é possível estabelecer políticas para garantir alta disponibilidade e contingenciamento em caso de falhas ou outages. No entanto, um bom desenho de arquitetura não se traduz em performance e robustez se toda a infraestrutura necessária para manter esse sistema não for confiável.

Desde a sua fundação, a Dock utiliza a AWS como provedor de serviços de infraestrutura, fazendo com que tenhamos 100% da nossa energia voltada para o desenvolvimento do nosso negócio.
Essa parceria tem nos proporcionado desenvolver produtos que atendam as necessidades de nossos clientes de maneira rápida, integrada e escalável, suportada pelos altos níveis de SLA dos serviços da AWS. A consequência disso é também um elevado nível de SLA dos nossos serviços, proporcionando uma experiência de tecnologia capaz de suportar com tranquilidade o crescimento dos nossos clientes.

We think technology so you don’t have to.