Implementation Patterns and Performance Tuning

The canonical indexing pattern stores each point as a 64 bit geohash integer as a secondary ordered key alongside the object ID and optional timestamp. For sharding, use a short 3 to 5 character prefix as the partition key to distribute writes (32 cubed equals 32,768 to 32 to the power of 5 equals 33.6 million possible prefixes), with the full geohash plus object ID as the sort key to preserve scan locality within each partition. Monitor per partition item counts continuously; when a partition exceeds capacity thresholds like 10 million items or 10 GB, split by increasing prefix length from 4 to 5 characters, redistributing load across 32 child partitions. Query optimization starts with precision selection: choose the smallest precision where cell diagonal is less than or equal to query radius. For dynamic precision, precompute and store multiple geohash lengths (5, 6, 7, 8 characters) per point to enable query time selection without recomputation. Execute 9 neighbor range scans in parallel when possible; in systems like DynamoDB or Cassandra, this translates to 9 concurrent partition queries that complete in one network round trip. Merge results in memory, deduplicate by object ID using a hash set, then apply exact haversine distance filtering to remove false positives. Expect 10 to 50 percent candidate overfetch at good precision; if measured overfetch exceeds 2 times, adjust precision finer. For aggregations and heatmaps, emit metrics keyed by the chosen geohash prefix at appropriate precision per zoom level: precision 5 for country/region view (4.9 kilometer cells), precision 6 for city districts (1.2 kilometer cells), precision 7 for neighborhoods (153 meter cells), precision 8 for street level (38 meter cells). With 100 million points, precision 6 yields at most 1.07 million possible buckets but only 10,000 to 100,000 are actually populated, easily fitting aggregation state in memory. Use sparse datastructures like hash maps or tries to avoid allocating empty cells. Cache aggregated tiles with geographic keys to serve repeated map requests without recomputation.

Key value production setup: 500 million locations sharded by 4 character geohash prefix across 512 partitions (consistent hashing maps prefixes to nodes). Average 1 million items per partition, 10 GB per node. Proximity query scans 9 ranges in parallel, fetches 600 to 1,000 candidates in 5 to 8 milliseconds, filters to 400 results. Achieves 50,000 queries per second cluster wide with p99 under 20 milliseconds.

Aggregation real numbers: Heatmap of 200 million food deliveries uses precision 6 for city view. Emit geohash bucket per delivery, aggregate counts in memory hash map. Only 80,000 buckets populated globally (out of 1.07 million possible), consuming 5 MB for counts plus 20 MB for geohash keys. Single core aggregation completes in 8 to 12 seconds; cache tiles for 5 minutes to serve map requests.

Multi precision index: Rideshare driver locations stored with 5, 6, 7, 8 character geohashes as four separate index entries per driver. Storage increases from 8 bytes to 32 bytes per location (4 times overhead), but query optimizer selects optimal precision dynamically. At 1 kilometer radius, uses precision 7; at 5 kilometers, uses precision 6. Eliminates precision mismatch overfetch, reducing average candidate count from 1,200 to 600 and cutting p99 latency from 30 milliseconds to 12 milliseconds.