Problema

Com o aumento na demanda de requisições feitas para a API da Ingresse alguns processos se tornaram um tipo de gargalo. O exemplo que usarei durante este artigo será o nosso processo de definir se a sessão (data/hora) de um evento está disponível para venda ou não.

Cada requisição feita pelo usuário a nossa API faz uma grande quantidade de buscas no nosso banco de dados e no Redis. São operações simples e que não deveriam ser muito custosas, porém são muitos dados que temos que buscar, e isso em grande escala de requests se torna bastante custoso.

Prova de conceito

Desde o início dos estudos para completar esta tarefa de refatoração nós optamos por dividi-la em duas partes, sendo elas:

Construir a árvore completa de um evento

A ideia nesta etapa é fazer todo o processo de buscas necessárias nos bancos de dados, percorrer esses dados e construir a árvore que será consumida por outros processos.

Aqui foram criados os dois principais módulos (ou classes para quem estiver mais habituado com linguagens OOP) que são os que representam os nós e a árvore em si. Esses dois módulos são uma implementação simples de uma árvore e com eles nós conseguimos criá-la a partir de uma estrutura de evento que é a entidade carregada do banco de dados com suas respectivas associações como sessões, grupo de ingressos e ingressos.

node.ex

tree.ex

Calcular os status de sessões a partir de uma árvore já construída

Esta etapa é a responsável por consumir uma árvore já criada e percorrer sobre os nós dela para calcular o status de cada um. Neste ponto nós usaremos a árvore criada pela etapa anterior a esta, assim, conseguiremos percorrer por todos os nós dentro da árvore utilizando o algoritmo Postorder Traversal.

Para fazer os cálculos dos status nós decidimos utilizar pesos neles, o que significa que, cada status terá um peso de acordo com o tipo de status que ele é, com o intuito de podermos definir qual status é mais relevante comparado com outros.

É importante deixar claro que nós temos dois grupos de status que são: Disponível e Indisponível.
Dentro do grupo Indisponível nós temos outros tipos de status, que podem ser: sem estoque, vendas não iniciadas, encerrado, etc, e esses sim tem o peso mencionado acima.

Nesta estapa também decidimos usar uma tabela ETS para guardar o status de cada nó e dar como resposta para nosso cliente.

Recursive Traversal

Depois de termos concluido essas duas etapas, começamos a pesquisar qual seria a melhor forma de construirmos a árvore e evitar ter que construí-la toda vez que alguém fizesse algum request para nosso serviço. Diante disto, pensamos em cachea-la no Redis como JSON, porém algumas árvores seriam muito grandes e parsear o JSON sempre seria algo custoso, depois de algumas pesquisas, achamos algo que poderia funcionar para a gente, em Elixir podemos facilmente transformar uma struct em um binário usando a função term_to_binary do Erlang, e tendo esse binário podemos usar um algoritmo de hash, assim teremos a hash de uma estrutura válida para guardarmos em algum tipo de cache e então reconstruir a árvore sem executar muitos processos usando a função binary_to_term do Erlang.

# iex

iex(1)> tree = Tree.build(event)
%Tree.Node{
  childs: [
    %Tree.Node{
      childs: [
        %Tree.Node{
          childs: nil,
          name: 55089
        }
      ],
      name:26190
     },
     %Tree.Node{
       childs: [],
       name: 26230
     }
  ],
  name: "Teste arena alterado"
}

iex(2)> binary = tree |> :erlang.term_to_binary()
<<131, 116, 0, 0, 0, 3, 100, 0, 10, 95, 95, 115, 116, 114, 117, 99, 116, 95, 95, 100, 0, 16, 69, 108, 105, 120, 105, 114, 46, 84, 114, 101, 101, 46, 78, 111, 100, 101, 100, 0, 6, 99, 104, 105, 108, 100, 115, 108, 0, 0, ...>>


iex(3)> hash = binary |> Base.encode64()
"g3QAAAADZAAKX19zdHJ1Y3RfX2QAEEVsaXhpci5UcmVlLk5vZGVkAAZjaGlsZHNsAAAAAnQAAAADZAAKX19zdHJ1Y3RfX2QAEEVsaXhpci5UcmVlLk5vZGVkAAZjaGlsZHNsAAAAAXQAAAADZAAKX19zdHJ1Y3RfX2QAEEVsaXhpci5UcmVlLk5vZGVkAAZjaGlsZHNkAANuaWxkAARuYW1lYgAA1zFqZAAEbmFtZWIAAGZOdAAAAANkAApfX3N0cnVjdF9fZAAQRWxpeGlyLlRyZWUuTm9kZWQABmNoaWxkc2pkAARuYW1lYgAAZnZqZAAEbmFtZW0AAAAUVGVzdGUgYXJlbmEgYWx0ZXJhZG8="

Tendo esta hash, podemos voltar à estrutura usando o caminho inverso.

hash = "g3QAAAADZAAKX19zdHJ1Y3RfX2QAEEVsaXhpci5UcmVlLk5vZGVkAAZjaGlsZHNsAAAAAnQAAAADZAAKX19zdHJ1Y3RfX2QAEEVsaXhpci5UcmVlLk5vZGVkAAZjaGlsZHNsAAAAAXQAAAADZAAKX19zdHJ1Y3RfX2QAEEVsaXhpci5UcmVlLk5vZGVkAAZjaGlsZHNkAANuaWxkAARuYW1lYgAA1zFqZAAEbmFtZWIAAGZOdAAAAANkAApfX3N0cnVjdF9fZAAQRWxpeGlyLlRyZWUuTm9kZWQABmNoaWxkc2pkAARuYW1lYgAAZnZqZAAEbmFtZW0AAAAUVGVzdGUgYXJlbmEgYWx0ZXJhZG8="

decoded_hash = Base.decode64!(hash)
<<131, 116, 0, 0, 0, 3, 100, 0, 10, 95, 95, 115, 116, 114, 117, 99, 116, 95, 95, 100, 0, 16, 69, 108, 105, 120, 105, 114, 46, 84, 114, 101, 101, 46, 78, 111, 100, 101, 100, 0, 6, 99, 104, 105, 108, 100, 115, 108, 0, 0, ...>>

structure = :erlang.binary_to_term(decoded_hash)
%Tree.Node{
  childs: [
    %Tree.Node{
      childs: [
        %Tree.Node{
          childs: nil,
          name: 55089
        }
      ],
      name:26190
     },
     %Tree.Node{
       childs: [],
       name: 26230
     }
  ],
  name: "Teste arena alterado"
}

Resultados Obtidos

Aqui devemos considerar os seguintes atributos

ips - iterations per second: a quantidade de iterações que podemos executar a cada segundo.
median: a mediana dos tempos de execução calculada no benchmark

Events

Queries

Performance Statistics

Memory Usage Statistics

Builds

Performance Statistics

Memory Usage Statistics

Recursive Traversal

Performance Statistics

Memory Usage Statistics

Tree to binary

Performance Statistics

Memory Usage Statistics

Binary to Hash

Performance Statistics

Memory Usage Statistics

Serialize

Performance Statistics

Memory Usage Statistics

Com esses resultados temos apenas uma preocupação no momento que é a quantidade de memória utilizada no algoritmo recursive traversal, por ser uma função recursiva nós já tinhamos em mente que ela usaria bastante memória e isso pode nos trazer problemas em um cenário de um evento gigante, o evento exemplo 34477 já é um evento considerado grande para nós devido a quantidade de ingressos e sessões que ele possui. Talvez iremos procurar resoluções para esse possível problema e acredito que se conseguirmos achar algo iremos trazer em um futuro post.

Conclusão

No final dessa POC conseguimos comprovar que nós conseguimos ter o mesmo cálculo que temos hoje, porém utilizando a estrutura de árvore que montamos para esse caso que se provou muito mais eficiente que o que temos hoje, pois os resultados que tivemos se provaram muito eficientes para diversos casos que temos hoje em nosso sistema.

Agradecimentos especiais ao Arthur por me orientar e acompanhar durante o processo de desenvolvimento!

Espero que gostem do post.

Até uma próxima!