Desenvolvimento

14 jul, 2017

Re-arquitetando pagamentos em dinheiro e carteira digital para a Índia com engenharia da Uber

Publicidade

A Uber está desenvolvendo uma plataforma de pagamento para a Índia que permite às equipes de operações coletar e distribuir de forma transparente pagamentos de dinheiro e carteira digital para os motoristas. Neste artigo, o engenheiro de software baseado em São Francisco, Yijun Liu, reflete sobre suas experiências trabalhando com a equipe de engenharia da Uber Índia em Bangalore para arquitetar este sistema de pagamento renovado.

Como membro da equipe da Uber’s Payments Efficiency/Eficiência de Pagamentos da Uber, sou responsável pelo desenvolvimento de sistemas de pagamento para nossas equipes de operações em todo o mundo. Em cada região, operamos de forma diferente nos pagamentos e, como resultado, nenhum sistema de pagamento é exatamente similar a outro.

O uso de cartão de crédito não é tão comum em países do Sudeste Asiático. Então, a Uber construiu um sistema de pagamento em dinheiro em 2015 para tornar nossos serviços mais acessíveis a esses mercados. Habilitar pagamentos em dinheiro apresenta novos desafios, garantindo que os passageiros tenham dinheiro disponível para o processamento e coleta de comissões de motorista.

Carteiras digitais são uma segunda opção de pagamento para passageiros na Índia. Em outubro passado, a desmonetização da moeda fez com que o uso da carteira digital subisse rapidamente, mas muitos provedores ainda não amadureceram e se estabilizaram em seus mercados locais. Ao mesmo tempo, as tecnologias de verificação de identificação, como autenticação em duas etapas e senhas únicas, complicam a experiência de pagamentos de passageiros acostumados a usar transações em dinheiro. Enquanto as carteiras digitais são eficientes e de boa execução, ainda há espaço para melhorar a experiência do passageiro.

Desde janeiro de 2017, tenho trabalhado na Engenharia da Uber em Bangalore para ajudar a equipe a reconstruir e enviar nosso sistema de pagamento para a Índia. Nas seções a seguir, descrevo o nosso sistema anterior, destaco seus problemas e discuto o modo como os abordamos arquitetando uma plataforma de pagamento mais transparente e conveniente para nossas equipes de operações e motoristas.

O engenheiro baseado em São Francisco, Yijun Liu, trabalha na Engenharia da Uber India em Bangalore para enviar um sistema de pagamento atualizado para a Índia

Coleta da comissão na Índia

Uma vez que a moeda forte desempenha um papel importante no mercado indiano, um dos principais focos da Uber Bangalore é otimizar o nosso sistema de coleta de comissões existente para transações em dinheiro. Embora o sistema existente funcione bem em algumas partes do mundo, a popularidade das transações em dinheiro e a diversidade dos cenários de pagamento na Índia exigem uma solução mais escalável e configurável.

Conceitualmente, o sistema de pagamento da Uber opera como um pipeline de dados que transforma pagamentos de viagem (dinheiro) em moeda digital antes de ser coletado por um sistema de desembolso que paga aos motoristas, seja por depósito direto ou carteira digital.

Imitando o fluxo do rio Ganges, nosso pipeline de dados de pagamento consiste em um evento (uma corrida ou requisição de entrega); uma ordem (a representação monetizada do evento); um acordo (a decisão de resolver ou contestar a transação entre um determinado pagador/beneficiário); e coleta/pagamento (ação de cobrar e coletar o dinheiro e pagar o motorista via e-wallet ou depósito direto).

O fluxo do rio Ganges, diagramado acima, ilustra este pipeline em um nível alto. O Ganges começa como um pequeno riacho no Himalaia, depois atravessa várias cidades como Rishikesh, Haridwar, Allahabad e Varanasi. Em cada fase, o Ganges cresce mais e mais profundamente até que seus vastos fluxos desaguam no Oceano Índico na Baía de Bengala.

Da mesma forma, o pipeline de dados do sistema de pagamento começa com informações básicas do evento (como duração e distância da viagem) que converte em detalhes da ordem de pagamento, depois para estratégias de liquidação e, finalmente, para a coleta ou desembolso real pelo provedor do serviço de pagamento, concluindo a transação. Quando o dinheiro é incorporado à equação como uma opção de pagamento, o pipeline torna-se muito mais complexo e os serviços bancários digitais de terceiros devem ser incorporados de forma a não perturbar o fluxo do sistema.

Adicionando dinheiro à equação

Quando lançamos o nosso sistema de coleta de dinheiro na Índia, coletamos pagamentos de passageiros e parceiros de motoristas pagos através de nossos sistemas de pagamento de motorista. Recentemente, no entanto, o crescimento global da Uber e os novos requisitos de negócios exigiram um pipeline de coleta revisado para comissões de viagem em dinheiro. Para construir este pipeline, tivemos que concatenar o pipeline de coleta de dinheiro com o pipeline de pagamento do motorista e vincular várias etapas entre os dois.

Esse trabalho foi desafiador para dizer o mínimo: como uma analogia, imagine juntar o rio Sindhu com o Ganges cavando canais; se essas rotas não forem mantidas, o excesso de água pode inundá-los facilmente. Dado o montante das operações em dinheiro na Índia e no Sudeste Asiático, o sistema de pagamento em dinheiro inevitavelmente se inunda com o tráfego. Além disso, cada região lida com a coleta de dinheiro ligeiramente diferente de acordo com as práticas do motorista e as necessidades do negócio.

Nosso antigo sistema de pagamento não pôde processar comissões de dinheiro por dois motivos:

  1. Do ponto de vista dos sistemas, as etapas extras entre o motorista e as condutas do passageiro poderiam causar inconsistências de dados. Quando o sistema guarda/salva o estado no banco de dados, envia notificações, registra entradas e chama o serviço de nível seguinte. Falhas parciais durante o tráfego pesado podem resultar em dados inconsistentes, mesmo que essas ações ocorram de forma assíncrona através de camadas de blocos try-catch;
  2. Do ponto de vista das empresas, as cidades da Índia têm diferentes cenários de pagamento em dinheiro. Eles variam em tarifa de viagem, volume de viagem total, canais de coleta e preferências de tratamento de caixa. Devido a essas diferenças, as equipes de operações da cidade precisam de maneiras versáteis de definir e executar suas estratégias de coleta. Como o sistema antigo estava mais em suas práticas de coleta, não poderia escalar para cenários personalizados.
Problemas de escalabilidade surgem quando os efeitos colaterais são disparados de forma assíncrona

Conforme ilustrado na Figura 2, o evento flui através deste pipeline de coleta: (1) escrevendo um evento para um banco de dados, (2) desencadeando vários efeitos colaterais (como enviar emails ou mensagens SMS) de forma assíncrona, (3) chamando a interface do próximo serviço para pedir por novas ações e (4) registrando essas interações. Embora esse fluxo pareça lógico, existem três armadilhas para esse projeto:

  • Quando muitas chamadas acontecem simultaneamente, isso pode sobrecarregar o serviço a jusante e causar tempo de espera. Independentemente das falhas a jusante, o sistema grava dados no banco de dados, potencialmente causando discrepâncias de dados entre (1) e (3);
  • Da mesma forma, chamadas assíncronas para desencadear efeitos colaterais (2) também podem oprimir o sistema e o tempo limite. Isso pode impedir que notificações de SMS sejam entregues aos motoristas, impedindo que eles recebam instruções de coleta de pagamento;
  • Uma vez que as chamadas para o próximo serviço (3) são normalmente assíncronas, o sistema grava uma entrada de registro, independentemente do resultado no terceiro ponto de conexão. Portanto, independentemente desse comportamento de registro, não há garantia de sucesso.

Construindo um sistema de pagamento de próxima geração

Para resolver esses problemas e implantar um sistema de pagamento mais avançado, precisávamos reconstruir o fluxo com uma arquitetura atualizada e criar uma maior flexibilidade sobre a forma como calculamos os pagamentos do passageiro.

Reescrita de arquitetura

Nossa solução arquitetônica para o primeiro problema foi reverter o fluxo de chamadas com filas. Em vez de confiar em um serviço para chamar todos os métodos ao mesmo tempo, um serviço independente recebe os eventos do banco de dados um a um. Para cada operação bem-sucedida, este serviço grava instruções de efeitos colaterais na fila e, em seguida, os efeitos laterais e os serviços a jusante simplesmente escutam, obtendo dados à sua própria velocidade.

Na nossa nova arquitetura, um pico de tráfego súbito apenas congestiona temporariamente a fila, mas nunca perde nenhum dado ou falha em não executar ações importantes. Este projeto renova a arquitetura do sistema de pagamento, conforme descrito na Figura 3.

Nossa nova arquitetura do sistema de pagamento inverte o fluxo de chamadas de eventos com filas, evitando que o tráfego expire o sistema

Personalização de coleta de dinheiro

Para abordar a diversidade das preferências de coleta de caixa da Índia, precisávamos entender as maneiras pelas quais essas estratégias diferem entre as regiões, incluindo a quantidade e frequência de coleta desejada por motorista e a ordem em que as equipes de operações provocam efeitos colaterais.

Se escrevemos diretamente uma lógica de negócios que personaliza as condições de coleta no código do backend, devemos desenvolver fluxos diferentes para cada região, o que é ineficaz em termos de tempo e custo. Mais do que isso, cada vez que uma região precisa criar, ler, atualizar e excluir (CRUD) suas políticas de cobrança, precisaremos de engenheiros para escrever e implantar um novo código, esgotando ainda mais a nossa eficiência.

Para abordar essas condições, implantamos uma camada de configuração para representar todas as lógica de negócios e implementamos cada efeito colateral e transição de estado como módulos de unidade. Isso segrega a lógica de negócios na camada de configuração mais superior do código do módulo de backend, tornando ambos fáceis de reutilizar como componentes em um sistema de tipo móvel. Agora, sempre que as equipes de operações precisam modificar o fluxo de coleta para sua região, elas precisam apenas atualizar a camada de configuração. Quando as configurações se atualizam, o sistema de coleta recarrega fluxos para essa região com base nos módulos de unidade da configuração. Abaixo, demonstramos o nosso novo mecanismo de sistema de coleta:

Nosso novo sistema é capaz de fazer malabarismos com múltiplos efeitos colaterais por região/configuração

Nossa atualização também resolve problemas enfrentados pelos usuários. No sistema antigo, confiamos em SMS e e-mails para notificar o status de cobrança aos nossos motoristas e não integravam carteiras locais e contas bancárias no aplicativo. Enquanto os SMS e os emails são uma maneira viável de comunicar atualizações aos nossos motoristas em outras partes do mundo, os usuários podem sofrer limitações na Índia e no Sudeste da Ásia por vários motivos, incluindo:

  1. Eles não recebem nossas mensagens SMS se as empresas locais de telecomunicações as interpretam como fraude;
  2. Eles não têm acesso fácil a emails e nem conferem com frequência;
  3. Eles precisam entrar em sua carteira digital para verificar seus saldos, o que pode ser um processo demorado e inconveniente.

Para resolver essas três preocupações, integramos carteiras de motorista no próprio aplicativo parceiro, aliviando o inconveniente de ter que alternar entre os dois aplicativos para verificar seu saldo.

Além disso, aperfeiçoamos nossos canais de comunicação, mudando fortemente de SMS e emails para notificações e páginas no aplicativo por região. Esta nova funcionalidade torna mais fácil e mais transparente compartilhar informações importantes com os motoristas sobre a cobrança de pagamentos.

Pagamentos de engenharia além da Índia

Essas mudanças de backend e frontend em nosso sistema de pagamento em dinheiro fornecem flexibilidade e facilidade ao usuário necessárias para a Uber criar soluções de transporte flexíveis na Índia e no Sudeste Asiático.

O re-projeto de sistemas de pagamento e cobrança em dinheiro da Engenharia da Uber Índia tem efeitos de longo alcance para além de nossos próprios usuários; nossa inovação em tecnologias de pagamento está na vanguarda da digitalização do mundo dos pagamentos da Índia. Além de construir nossos sistemas de pagamento, nossa equipe baseada em Bangalore também se concentra nos projetos de crescimento do motorista, experiência do passageiro, tecnologia de veículos e mapas, todos campos desafiadores – mas gratificantes – com enormes implicações para o mercado maciço e emergente da Índia.

Yijun e a equipe de Engenharia da Uber Índia em Bangalore tira uma pausa de re-arquitetar pagamentos para sorrir para a câmera

Interessado em trabalhar em desafios de engenharia que surpreendem os limites da escala? Considere se candidatar a um cargo na equipe de Engenharia da Uber Índia.

Yijun Liu é engenheiro de software na equipe de Eficiência de Pagamentos da Uber e Mrina Natarajan é gerente de programa técnico da equipe da Experiência do Desenvolvedor da Uber.

***

Este artigo é do Uber Engineering. Ele foi escrito por Yijun Liu & Mrina Natarajan. A tradução foi feita pela Redação iMasters com autorização. Você pode conferir o original em: https://eng.uber.com/india-payments/