O que iFood, Yelp e Tinder têm em comum? Todas são plataformas que oferecem, por causa da demanda por proximidade dos participantes, de serviços baseados em localização.
 | Relacionando plataformas e a transformação digital Transformação Digital e Ágil Plataformas estão revolucionando a estratégia. Muitas das organizações digitais que estão transformando o mercado estão implantando, consciente ou inconscientemente, plataformas. Deseja saber mais sobre o assunto? |
Nesse capítulo, discutiremos como implementar serviços de localização de maneira eficiente. Trata-se de um desafio interessante quando analisado sob a perspectiva da escala.
Mais uma vez, iremos utilizar um cenário fictício para fundamentar decisões.
O que é uma LBS?
Um serviço baseado em localização (LBS) é um tipo especial de serviço de software que usam dados e informações geográficas para fornecer serviços ou informações aos usuários. LBS pode ser usado em uma variedade de contextos, como saúde, busca de objetos internos, entretenimento, trabalho, vida pessoal, etc.
Coletando informações para o Haiku
 | Architecture Haiku Não sabe o que é um “Architecture Haiku”? Consulte agora esse tópico no capítulo em que tratamos sobre documentação de software. Acessar tópico |
Desejamos conectar potenciais clientes com prestadores independentes de serviço, conforme proximidade.
Prestadores de serviço podem cadastrar-se a plataforma, especificando condições de trabalho e horários de funcionamento.
Assumimos que a plataforma contará com 150 milhões de usuários ativos (DAU) e 50 milhões de prestadores de serviço disponíveis. Cada usuário faz, em média, 4 consultas por dia.
As principais funcionalidades do sistema são:
- Relacionar prestadores próximos de um consumidor, baseando-se em sua localização atual (latitude e longitude);
- Permitir que prestadores de serviço incluam, atualizem ou removam suas ofertas de trabalho;
- Consumidores devem poder consultar detalhes das ofertas dos prestadores relacionados.
Os principais atributos de qualidade são disponibilidade e escalabilidade.
Eventualmente, pode ser necessário segregar dados geograficamente para atender normas de segurança de dados.
Algumas estimativas de “papel de pão”
Com base nas informações explicitadas no Haiku, em nosso cenário fictício, é possível elaborar algumas estimativas, grosseiras, mas já suficientes para orientar algumas decisões de design.
Proposta ingênua de design arquitetural
Uma primeira abordagem, quase instintiva, inclui segmentar as operações administrativas (manutenção dos prestadores de serviço) das buscas. Essa segmentação pode ocorrer, no primeiro nível, nos servidores de aplicação, e nas bases de dados relacionais, com o master operando para atender tarefas administrativas e réplicas suportando as buscas.
Como cada prestador de serviço possui, naturalmente, sua localização (latitude e longitude) na base de dados, a busca poderia simplesmente filtrar aqueles cujo a distância for aceitável.
O problema natural dessa abordagem é o custo das consultas que naturalmente ocorrem com buscas full scan. Aliás, é importante destacar que a adoção de índices (para longitude ou para a latitude) minimiza o problema, reduzindo os datasets, mas não o resolve plenamente.
 | Uma restrição natural para escalabilidade surge nas demandas por computação ou agregação nas consultas. |
Organizando informações para gerar as primeiras ADRs
| Architecture Decision Record O bom arquiteto garante que decisões sejam tomadas, justificadas e comunicadas! Precisa relembrar o que é uma ADR? Visite o tópico onde introduzimos o conceito. Acessar tópico |
A partir das informações obtidas para formulação do Haiku e dos “números no papel de pão”, já é possível indicar algumas ADRs em status de “aberta para discussão”. Essas ADRs indicariam a “inclinação arquitetural” para diversos aspectos importantes, possibilitando debates com especialistas.
Endpoints candidatos
Parece ser adequado desenvolver o serviço como uma API REST. Destacam-se cinco endpoints principais:
- Obter lista de prestadores de serviço com
GET /nearby?lat=<latitude>&lon=<longitude> - Obter informações sobre um prestador de serviço com
GET /business/<id> - Adicionar informações sobre um novo prestador de serviço com
POST /business - Atualizar informações sobre um prestador de serviço com
PUT /business/<id> - Remover informações sobre um prestador de serviço com
DELETE /business/<id>
| Filosofia REST APIs (supostamente) REST são bem comuns. Deseja entender mais sobre a filosofia REST? Consulte o capítulo destinado a esse tema. Acessar tópico |
Opção de representação #1: Adotar Geohash
O principal problema com a abordagem ingênua, proposta anteriormente, é que o banco de dados consegue melhorar o desempenho das consultas a partir da latitude ou da longitude. Logo, naturalmente, o caminho para melhores resultados é gerar uma única chave de busca. Uma abordagem comum é pela adoção de Geohash.
 | Geohash Geohash é um sistema de geocódigo de domínio público inventado em 2008 por Gustavo Niemeyer que codifica uma localização geográfica em uma pequena sequência de letras e dígitos.Interessado em saber mais, consulte o artigo na Wikipedia. |
A adoção de geohashs implica no zoneamento de uma região em quadrantes e sub-quadrantes, em tantos níveis quanto necessário, até que o tamanho de uma célula estiver em conformidade com a área de busca em que se deseja atuar.
Cada quadrante pode, em qualquer nível precisa de apenas 2 bits para ser indicado que podem ser, então, facilmente convertidos em sequências de caracteres usando-se, por exemplo, Base32.
| Base32 Base32 é o sistema numérico de base 32. Ele usa um conjunto de 32 dígitos, cada um dos quais pode ser representado por 5 bits (25). Uma maneira de representar números Base32 de forma legível é usando um conjunto padrão de 32 caracteres, como as vinte e duas letras maiúsculas A–V e os dígitos 0-9. No entanto, muitas outras variações são usadas em diferentes contextos.Deseja saber mais? |
Para mapear o mundo inteiro (latitude com intervalo entre -90 e +90, longitude com intervalo entre -180 e +180), seriam necessários apenas 6 caracteres para determinar regiões com 4,9km x 2,5km.
Geohashes são fáceis de usar e implementar. Entretanto, ignoram aspectos como densidade de cada região.
Opção de representação #2: Adotar Quadtrees
A principal desvantagem da abordagem baseada em geohashes é ignorar densidade em cada região. Essa restrição pode ser facilmente suplantada pela adoção de Quadtrees.
| Quadtree Uma quadtree é uma estrutura de dados em árvore na qual cada nó interno tem exatamente quatro nós filhos. Quadtrees são usados com mais frequência para particionar um espaço bidimensional subdividindo-o recursivamente em quatro quadrantes ou regiões. Os dados associados a uma célula folha variam de acordo com a aplicação, mas a célula folha representa uma “unidade de interesse espacial”. Deseja saber mais? |
Para nosso serviço, um nó folha poderia ser especificado por um número mínimo de prestadores de serviços atuantes (por exemplo, 150).
Quadtrees são pequenas o suficiente para serem mantidas inteiramente na memória tendo como custo principal sua computação.
| Dados consultados frequentemente e raramente modificados, devem ser mantidos na memória, sempre que possível, evitando tráfego de rede. |
Quadtrees são fáceis de consultar, mas são caras de “computar”.
| Estruturas em memória, com alto custo de computação, podem ser preservadas, de maneira mais econômica, serializadas em um repositório central (reconstruídos quando necessário). |
Pontos que ainda necessitam reflexão
O processo de elaboração da arquitetura deve ser incremental. Tão importante quanto relacionar decisões realizadas é indicar claramente o que ainda precisa ser ponderado.
Com relação ao design LBS é importante, ainda, considerar:
- Como respeitar eventuais normas relacionadas a segurança de dados, com restrição a informações de prestadores de serviços? Usando como sharding key a geohash do prestador de serviço para eleição do datacenter?
- Que método usar para determinar disponibilidade de “prestadores de serviços” conforme, por exemplo, horários de funcionamento? O custo da busca, uma vez que há poucos prestadores retornados em cada consulta, no banco é significativo?
Takeaways
A elaboração desse “início de trabalho arquitetural” para um “LBS” permite algumas lições importantes:
- Mesmo soluções muito simples se tornam desafiadoras quando envolvem suporte a escala.
- Desempenho, em muitas ocasiões, é garantido pela escolha de boas estruturas de dados.
- Sempre há mais de uma alternativa para resolver um problema arquitetural e, consequentemente, trade-offs.
- Conhecer boas estruturas/estratégias de dados (como Geohashes e quadtrees) pode ajudar a viabilizar algumas propostas de design.
Dúvidas ou sugestões? Deixe suas contribuições nos comentários.
