Como funcionam os serviços de busca por proximidade no Brasil
A maioria das pessoas usa "o que esta perto" como se fosse uma função mágica, mas na prática é apenas uma consulta geoespacial básica com alguns filtros adicionais. O funcionamento depende de três camadas: o dispositivo captura suas coordenadas GPS, o servidor recebe essas coordenadas e consulta um banco de dados com índices espaciais, e depois aplica filtros de relevância antes de devolver os resultados. Quando você abre qualquer app que mostra resultados "perto de você", está essencialmente fazendo uma query do tipo "encontre pontos dentro de um raio de X metros". A parte complicada não é a lógica em si, mas a escala e a qualidade dos dados que alimentam o sistema.
A diferença entre geolocalização e o que esta perto
Geolocalização é apenas saber onde você está. O que esta perto é saber onde você está, cruzar com um catálogo de estabelecimentos ou serviços, calcular distâncias reais (não em linha reta), considerar trânsito ou tempo de percurso, e classificar por relevância. Muitos apps confundem essas etapas. Eu trabalhei em um projeto onde o cliente queria algo simples: mostrar farmácias abertas nas proximidades. O problema era que o banco de dados tinha cerca de 40 mil pontos cadastrados, mas 30% tinham coordenadas erradas ou desatualizadas. O resultado era o app sugerindo uma farmácia que na verdade era um terreno baldio há seis anos. A solução foi implementar uma validação em lote usando dados do Google Places como referência, e depois um sistema de reporte pelos próprios usuários para manter a precisão ao longo do tempo.
O ponto que ninguém conta é que distância real não é a mesma que distância em linha reta. Um estabelecimento a 500 metros em linha reta pode levar 15 minutos a pé se tiver que fazer uma curva grande ou atravessar um rio. Apps profissionais usam rotas reais via APIs de mapas, o que aumenta drasticamente o custo computacional.
Implementação prática e armadilhas comuns
Se você quer construir algo que responda adequadamente a o que esta perto, comece pelo banco de dados. PostgreSQL com a extensão PostGIS é o padrão da indústria há mais de uma década. Índices espaciais do tipo R-Tree ou GiST permitem consultas de raio em milissegundos mesmo com milhões de registros. MySQL tem suporte parcial desde a versão 8.0, mas a performance cai significativamente em volumes maiores. O erro mais comum que vejo é calcular a distância no código depois de trazer todos os resultados do banco. Isso funciona bem com 200 registros. Com 200 mil, seu servidor vai entrar em colapso. A distância deve ser calculada no SQL usando funções como ST_DWithin ou Haversine, limitando o resultado antes de ele sair do banco.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro problema crônico é a latência. Uma consulta geoespacial bem feita leva em média 15 a 50 milissegundos no PostGIS com índice adequado. Mas se você precisar calcular rotas reais via API de terceiros, o tempo sobe para 200 a 800ms por estabelecimento. Isso significa que listar 20 resultados com rotas pode levar de 4 a 16 segundos, o que é inaceitável para uma experiência mobile. A solução usada no mercado é paginar os resultados e calcular rotas sob demanda, mostrando primeiro apenas a distância em linha reta. Cuidado também com a privacidade. No Brasil, a LGPD exige que o consentimento do usuário seja explícito para coleta de localização. Muitos desenvolvedores tratam isso como um checkbox genérico, mas a legislação é mais rigorosa do que parece. Se o app funciona com base na localização, isso precisa estar claro no momento da permissão, não escondido em termos de uso de cinco páginas.
Uma limitação séria que pouca gente menciona é a disparidade entre cidades grandes e pequenas. Em São Paulo ou Curitiba, o density de estabelecimentos permite que o algoritmo seja preciso. Em cidades do interior com menos de 50 mil habitantes, a base de dados pode ter apenas 200 estabelecimentos cadastrados, e muitos com informações desatualizadas. Nesse cenário, "o que esta perto" retorna resultados irrelevantes simplesmente porque não há dados suficientes. A alternativa viável nesses casos é integrar ao OpenStreetMap, que costuma ter cobertura melhor para regiões pequenas, ou depender de dados crowdsourcados com moderação ativa.
Quais ferramentas usar em 2024
Para quem está começando, o caminho mais direto é usar a API do Google Places Nearés search ou da Here Technologies. Ambas cobram por requisição, mas eliminam a complexidade de infraestrutura. Um projeto pequeno com 10 mil usuários ativos diários pode gerar uma fatura mensal de R$ 200 a R$ 500 só em chamadas de API. Se o volume crescer, migrar para uma solução self-hosted com PostGIS e um frontend que faça cache agressivo dos resultados reduz o custo em cerca de 80%. O trade-off é que você assume a responsabilidade pela manutenção dos dados e pela disponibilidade do serviço.
Não existe solução perfeita para o que esta perto. Existe escolha entre precisão, custo e complexidade. Defina qual dessas variáveis é mais importante para o seu caso e construa a partir daí.
