Optimization of Reverse Geocoding Service: Caching, GeoHash, and LRU Strategies

Background: Reverse geocoding (converting latitude‑longitude to a structured address) is the most frequently called map service interface, with daily request volume of 200‑300 million. During peak periods the Gaode API QPS often exceeds limits, causing errors and forcing fallback to the internal LBS service.

Overall solution design: Identify the call volume of each node, conduct code reviews and business discussions to eliminate unnecessary calls, and apply caching mechanisms for the remaining high‑traffic nodes.

Information supplement: Existing reports only show business‑level metrics, so additional instrumentation was added to record call parameters per node, enabling precise analysis of which nodes generate excessive traffic.

Step‑by‑step optimization: Remove calls that are not required (e.g., duplicate reverse‑geocode triggered by the Gaode location component, or map zoom without center change). Reduce calls by limiting feature scopes (e.g., stop location‑following when the app is in background) and by reusing POI data instead of issuing extra reverse‑geocode requests.

Cache usage: Store reverse‑geocode results in a combined memory‑plus‑disk cache. The cache key is generated from latitude, longitude and request radius. To improve hit rate, nearby coordinates are aggregated using GeoHash.

GeoHash algorithm: GeoHash encodes a 2‑D coordinate into a string representing a rectangular area. Longer codes denote smaller areas. The algorithm converts latitude and longitude into binary, interleaves bits, groups them into 5‑bit chunks, and maps each chunk to a Base32 character (excluding a, i, l, o). The implementation uses GeoHash length 9, giving ~5 m error.

Cache eviction mechanisms: Primary eviction uses LRU (Least Recently Used). Additional dimensions include time‑based eviction (data older than 2 days) and access‑count eviction (data accessed more than 10 times is refreshed).

Cache algorithm optimization: Adopt LRU‑K, which only promotes an item to the main cache after it has been accessed K times, reducing cache pollution from one‑time accesses. Historical queue stores items until they reach K accesses; then they move to the cache queue. This approach is expected to improve hit rate by 10‑20%.

Disaster recovery: If both Gaode and self‑built services exceed QPS limits, the system falls back to a lower‑precision GeoHash7 (≈80 m) cache lookup; if the key is missing, the request is aborted after 2 seconds to relieve server pressure.

Anti‑fragility: Integration with MapService provides independent monitoring and DingTalk alerts for nodes exceeding QPS. The LBSAdmin platform enables dynamic downgrade without redeployment.

Results: Daily reverse‑geocode calls dropped from 200‑300 million to 20‑30 million after optimization.

Summary of key lessons: Maintain reverence: clearly understand code impact before optimization and ensure changes are gray‑released and reversible. White‑box optimization: base decisions on real‑world metrics rather than assumptions. Long‑term building: lay solid foundations for future improvements. Prevent fragility: avoid design that leads to frequent “break‑fix” cycles.

Authors: Chen Dongran, Liu Dabai, Ren Sailong, etc., from the Hellobike AI & Map Team.

Recruitment: Hellobike Map Team is hiring senior engineers (Shanghai, Hangzhou). Apply at https://careers.hellobike.com/