rthoth / caju

Desafio backend

caju

Desafio backend

O código fonte também está disponível na minha conta no github caju, caso a visualização desse arquivo Markdown não sejá muito agradável sem alguma ferramenta para visualizá-lo.

Plataforma

O projeto foi escrito em Scala (2.13.6) usando como plataforma principal o Akka (2.6.8) e Akka Http (10.2.4). O banco de dados utilizado é o MongoDB (5.0.0).

Build

Como um projeto Scala será necessário instalar o sbt.

Aviso importante: Nos testes automáticos eu utilizo uma lib docker-it-scala para levantar uma instância do MongoBD e assim o código é testado em vários momentos com um banco de dados real. Essa lib precisará que o seu usário possa utilizar o docker, nas distribuições Linux que já usei basta você adicionar o grupo docker ao seu usário aí não será necessário nenhum privilégio de super usuário para executar os testes.

O projeto foi criado para gerar imagem docker com a aplicação, para gerar imagem local basta abrir o terminal do sbt dentro do projeto e digitar:

docker:publishLocal

Será criada uma imagem docker caju/rthoth-authorizer:1.0.0 ela que deverá ser utilizada.

Execução

Para facilitar um pouco o processo de testagem manual/automática você precisará instalar o docker-compose, após isso só verificar que no projeto há um diretório docker onde está configurado um ambiente com uma instância da aplicação, uma instância MongoDB e uma ferramenta (Locust) que costumo utilizar para fazer alguns testes mais simples de carga.

Para executar basta ir com o terminal nesse diretório e chamar o docker-compose:

docker-compose up authorizer locust

Dessa forma como está aí apenas a saída padrão do containers da aplicação (authorizer) e do locust serão exibidos no terminal.

A aplicação está configurada por padrão para ouvir na porta 9999. Então para invocar o serviço basta chamar:

http://localhost:9999/authorize

Na descrição do desafio não foi definida nenhuma instrução de como criar as contas onde serão feitas as operações. Caso seja necessário para criar/atualizar as contas basta fazer como o exemplo abaixo:

POST http://localhost:9999/account

{
    "code": "XXXXX",
    "meal": 10000,
    "food": 10000,
    "culture": 10000,
    "cash": 100000
}

Internamente os valores monetários são representados como inteiros de centavos, apenas nesse serviço POST http://localhost:9999/account você precisa informar os valores em centavos. No serviço do desafio não é necessário fazer isso.

Caso tenha curiosidade de ver o Locust ele estará em http://localhost:8089.

Sobre o teste L4 e a implementação

Primeiramente. Como estamos falando de operações financeiras, imagino que talvez algumas transações realizadas quase ao mesmo tempo sejam um indicativo de fraude. Não sei, foi a primeira coisa que me ocorreu. Feito o comentário, como escrevi o desafio em Akka optei por implementar um ideia para resolver o problema. A solução é basicamente implementar o processo de autorização de transações em duas etapas, na primeira um Manager é responsável por alocar um Ator temporário responsável por liberar as transações para uma conta, enquanto esse Ator estiver vivo os pedidos para aquela conta são direcionados para ele, aí utilizo o modelo de atores implementado pelo Akka para garantir que as operações são feitas de forma não bloqueante e sequencial para aquele cartão e paralelas em relação as operações em outros cartões.

A imagem L4.png mostra uma máquina de estados desse Ator.

A: Representa o momento onde o ator espera o próximo pedido de autorização (Authorize) e também é o estado inicial.

B: Assim que um pedido chega o Ator procura em banco de dados as informações sobre a conta, equanto isso se outros pedidos forem feitos eles ficarão na lista de espera.

C: Quando a informação da conta chega se inicia o processo de detectar o mcc solicitado pelo teste L3. Nesse caso foi feita uma consulta simples em uma coleção no MongoDB com os dados dos Merchants conhecidos. Enquanto o mcc não for resolvido se outros pedidos forem feitos eles ficarão na lista de espera.

E: Com a etapa de determinação do mcc concluída é calculado o débito na conta, segundo as regras L1 e L2. Se a categoria do benecífico tem saldo é debitada dela, se não tiver é debitada da categoria especial CASH. Nesse caso implementei a determinação dos categorias em código mesmo, pelo que vi não haveria uma necessidade de uma dinamicidade para essa parte do desafio. Se não for possível realizar a transação é rejeitada e o Ator voltará para o estado inicial A.

F: Podendo realizar a operação a conta será atualizada, enquanto isso se outros pedidos forem feitos eles ficarão na lista de espera.

G: Se ocorrer uma falha na atualização da conta será enviada a resposta que a transação falhou e o Ator será direcionado para o estado inicial, se houver pedidos na lista de espera eles serão processados.

H: Se a atualização do banco foi bem sucedida será enviada a resposta indicando que a transação foi aprovada e o Ator voltará para o estado inicial, seguindo a mesma lógica de transição de G.

I: Se ocorrer uma falha na detecção do mcc será a enviada a resposta que a transação falhou e o estado será alterado para o inicial A, havendo solicitações pendentes eles serão processadas.

K e J: Se ocorreu uma falha com o repositório (MongoDB) de dados das contas o Ator ficará nesse estado, e o primeiro pedido de autorização que originou a o pedido será considerado falho e aí o estado será alterado para o inicial.

L: Esse estado pode ser alcançado de três formas. Quando em A o ator pode receber uma mensagem TTD (Time To Die) ou o estado B, nesses dois estados o ator está ocioso esperando novas solicitações ou esperando a informação da conta do banco de dados, se caso o ator ficar muito tempo (por volta de 100ms) ele recebe essa mensagem e entende que não pode mais continuar vivo. Importante, se caso o ator sair dos estados A e B antes da mensagem TTD chegar a contagem será reiniciada, indicando que há mais pedidos para aquela conta. Outra forma que o estado L pode ser alcançado é se a conta NÃO existir, nesse caso todas as transações serão canceladas! Uma vez alcançado esse estado o ator irá morrer, aí todas as transações em espera (no caso do banco estar lento) serão notificadas que falharam e o ator morrerá.

Considerações

Sobre representar os dados monetários como inteiros de centavos, sei que para esse tipo de dado a representação de ponto flutuante gera alguns probleminhas e usar alguma solução de precisão aribrária nesse caso não seria necessário, visto que é utilizada apenas uma operação de subtração e jogar o problema para representação com inteiros já é bem eficiente.

Espero que de alguma forma a explicação e código sejam interessantes.

Novamente obrigado pela oportunidade.

Obrigado,

Ronaldo Aparecido da Silva.