Redis is not a map you talk to over TCP

Redis is often thought of as a simple key-value store, but in certain scenarios, it becomes much more complex. A delivery app I work on uses Redis to manage route estimates for couriers, but relying on Redis alone can lead to inefficiencies and slower performance. The key challenge lies in deduplicating frequently repetitive route estimates.

Without a proper caching layer, the routing engine is repeatedly calculated for similar distances, leading to unnecessary work and latency. One solution is to use a process-local cache, but it must be shared among processes. Using raw coordinates for caching doesn't work well, so the solution is to use H3 hexagon coordinates for deduplication.

The resolution of H3 hexagons can be adjusted to balance hit rate and accuracy. Redis clustering further complicates the issue, as keys are distributed across 16,384 hash slots, making batching of commands difficult. To address this, a hash tag can be used to ensure keys land in the same slot. However, semantic tags like origin hex leads to hotspots, so arbitrary integer tags are chosen to evenly distribute keys across the cluster.

This involves an integer template that is brute-forced to find the appropriate slot for each key. By implementing these changes, the performance of the Redis system can be optimized for the specific needs of the delivery app.