Olá a todos!

No último mês, mergulhei de cabeça em um desafio ambicioso: otimizar a performance da API do MapBiomas Alerta. O objetivo era claro: entregar aos nossos usuários da API e desenvolvedores uma experiência mais rápida e eficiente, com respostas instantâneas às suas consultas. E posso dizer com orgulho que alcançamos esse objetivo pq nosso bentchmark de performance foi atingido com resultado em 10 vezes mais rápido que a versão anterior.

Por que a velocidade importa?

No universo da plataforma a velocidade com que podemos acessar e analisar informações é fundamental. No contexto do MapBiomas Alerta, isso significa que usuários, gestores ambientais e o público em geral podem tomar decisões mais rápidas e embasadas com base nos dados que fornecemos.

Para alcançar essa meta, implementamos uma série de otimizações na nossa API construída com GraphQL. Mantivemos a flexibilidade e a potência do GraphQL, mas focamos em melhorar a performance em todos os níveis e por estas e outras melhorias que vou falar abaixo decidimos chamá-la de "V2".

A origem do desafio

As novas funcionalidades exigiram da plataforma cruzamentos com uma variedade ainda maior de dados, incluindo imóveis rurais, geoparques, áreas de proteção, reservas da biosfera e outras categorias relevantes. Essa nova funcionalidade visavam análises mais detalhadas e específicas, permitindo aos usuários identificar as áreas de maior interesse e entender melhor as dinâmicas entre os cruzamentos espaciais dos alertas com as áreas de interesse.

Atualmente a plataforma conta com mais de 300 mil alertas publicados, cobrindo uma área de mais de 7 milhões de km² no Brasil, a base ainda conta com informações de cruzamento com os mais de 6 milhões de imóveis rurais e também com mais de 35 mil territórios diferentes entre eles biomas, cidades, estados, geoparques, assentamentos, terras indígenas, etc. São sentenas de milhões de registros que precisam ser cruzados e analisados para que o usuário possa ter a informação que deseja.

Porém a arquitetura da API original não estava preparada para lidar com essa quantidade de dados e complexidade de consultas. A cada nova funcionalidade, o tempo de resposta das consultas aumentava, tornando a experiência do usuário mais lenta e menos eficiente. Por isso a necessidade de otimizar a API.

Por dentro das Otimizações

Um dos principais pontos foi decidir utilizar Materialized Views no Postgres: Criamos views materializadas no nosso banco de dados Postgres para pré-calcular as consultas sobre as informações dos alertas. Isso significa que, ao invés de realizar cálculos complexos a cada requisição, a API pode simplesmente buscar os resultados já pré-calculados, resultando em um ganho significativo de performance.

Esta decisão só foi possível visto que os alertas, a entidade principal do banco de dado, são publicados semanalmente e a cada semana despendemos apenas alguns minutos para atualizar as MVs. Com isso, conseguimos manter a API sempre atualizada e com respostas instantâneas. Para quem nunca usou MVs, recomendo fortemente a leitura sobre o assunto para compreender se é uma boa solução para o seu problema, pois se não for bem utilizada pode trazer problemas ainda maiores de performance.

Olhando para o serviodr outro ponto importante foi mapear as queries mais demoradas e complexas realizadas na API GraphQL para permitir a redução do número de chamadas ao banco de dados e minimizando a quantidade de dados transferidos. Isso foi possível também com uso da infraestrutura de forma mais eficiente para garantir que a API possa atender a um número crescente de usuários e consultas que a plataforma possúi.

Também não podemos deixar de falar sobre o controle aprimorado da API com o uso de Batching e Caching em consultas no servidor. Sobre o cacheamento em memória utilizamos o já conhecido Redis para armazenar os resultados das consultas mais frequentes.

Aos desenvolvedores novatos e experientes, deixo aqui uma dica sobre cacheamento: Use com sabedoria. O cacheamento é uma ferramenta poderosa, porém nem todo dado é cacheável, por isso foi necessário identificar quais dados poderiam ser armazenados em cache e por quanto tempo, para garantir que as informações estejam sempre atualizadas e disponíveis para os usuários.

Resultados concretos

Graças a essas otimizações, conseguimos reduzir o tempo médio de resposta das consultas em 90% em comparação com a versão anterior da API com o dobro de informações. Isso significa que agora você pode obter as informações que precisa de forma muito mais rápida, seja para analisar um alerta específico, para gerar relatórios personalizados ou destravar novas funcionalidades da plataforma que virão por aí.

Logo, com estas novidade e novas funcionalidade, mais dados e maior velocidade da API, foram compensados, pois o trabalho em desenhar e implementar a API V2 é sem dúvida um marco importante para compartilhar aqui com vocês.

Espero que tenham gostado de conhecer um pouco mais sobre a jornada de otimização da API do MapBiomas Alerta. Se você tiver alguma dúvida ou quiser saber mais sobre o assunto, fique à vontade para deixar um comentário ou entrar em contato comigo.

Se desejar conhecer a API em ação, acesse a Plataforma MapBiomas Alerta e comece a explorar os alertas ou acesse a documentação da API em https://plataforma.alerta.mapbiomas.org/api.