Um pequeno serviço de transporte compartilhado que operava sob um acordo para um campus e os bairros vizinhos tinha uma regra rígida que não podia quebrar: embarques e desembarques tinham de ficar dentro de uma área de operação definida, acordada com a autoridade local que havia aprovado o serviço. Motoristas que deixavam passageiros fora desse limite, mesmo por uma distância curta, colocavam todo o acordo de operação em risco, e confiar que os motoristas avaliassem um limite a olho em um mapa de papel nunca seria confiável.
O serviço construiu a verificação com base em coordenadas, e não em endereços, já que o marcador de embarque do passageiro já era uma coordenada colocada em um mapa dentro do aplicativo, e não um texto digitado. Para essa coordenada bruta, o serviço usava o /v1/reverse para obter um endereço legível e a sua área administrativa, algo útil para mostrar ao passageiro um local de embarque confirmado e para a equipe que revisava depois qualquer viagem sinalizada, já que uma coordenada sozinha é difícil de ser conferida rapidamente por uma pessoa, enquanto um endereço resolvido não é.
A verificação do limite em si era uma comparação geométrica simples, feita pelo próprio backend do aplicativo, entre a coordenada do passageiro e o polígono que descrevia a área de operação aprovada, um cálculo que não exige um serviço externo quando você já tem uma coordenada para testar. Os endpoints de localização entravam para garantir que esse teste sempre tivesse uma coordenada real com que trabalhar, convertendo primeiro em coordenada, pelo /v1/forward, o que quer que o passageiro tivesse digitado no aplicativo, caso digitasse um endereço em vez de colocar um marcador.
Uma solicitação de embarque que ficava dentro do limite seguia normalmente. Uma que ficava fora dele, mesmo que ligeiramente, era recusada antes de qualquer motorista ser despachado, com uma mensagem explicando que o serviço não podia operar legalmente fora da sua zona aprovada, em vez de um motorista chegar e só então descobrir que não tinha permissão para fazer o embarque. Recusar cedo poupava o tempo do motorista e do passageiro e mantinha um registro limpo mostrando que o serviço estava aplicando ativamente o próprio limite, em vez de só descobrir as violações depois.
O serviço também usava o endereço obtido pela geocodificação reversa em viagens sinalizadas ou contestadas, já que um pequeno número de embarques caía exatamente na borda do limite e precisava de uma pessoa para confirmar se uma solicitação tinha de fato ficado dentro ou fora da área aprovada, algo muito mais fácil de julgar a partir de um endereço resolvido e do nome do bairro do que de um par de coordenadas brutas em um painel interno.
Esse tipo de aplicação de limites não é um problema técnico complicado depois que as peças de localização estão no lugar. A parte difícil era garantir que todo embarque e desembarque, qualquer que fosse a forma como tivesse sido informado no aplicativo, sempre terminasse como uma coordenada que a verificação geométrica do backend pudesse de fato usar, e isso ficava a cargo do /v1/forward e do /v1/reverse trabalhando juntos, dependendo da direção de onde vinham os dados.
O volume estava diretamente ligado ao número de corridas, uma ou duas consultas por viagem, uma carga de trabalho que ficou dentro da cota diária gratuita para um serviço desse porte operando em uma única área limitada. A documentação dos dois endpoints está em /docs/forward-geocoding/ e /docs/reverse-geocoding/.