The Distance Multiplier: Why Cachee Gets Faster the Further You Are from Redis

Here's something counterintuitive we discovered while benchmarking Cachee against AWS ElastiCache: the worse your network latency to Redis, the more Cachee helps.

Not a little more. Exponentially more.

Let us explain.

The Constant: 16 Microseconds

When Cachee serves a cache hit from its L1 memory, the latency is 16 microseconds. This number doesn't change based on where your Redis lives. It's a local hash table lookup—no network involved.

That 16μs is the same whether your Redis cluster is:

• In the same availability zone
• Across availability zones
• In a different AWS region
• On-premises behind a VPN
• On the other side of the planet

But the latency you're avoiding changes dramatically.

The Variable: Network Round-Trip

Without Cachee, every Redis command requires a network round-trip. That round-trip time depends entirely on distance:

Read the rightmost column. The speedup goes from 21x to nearly ten thousand. Same technology. Same proxy. The only variable is how far away Redis is.

Why This Matters More Than You Think

Most Apps Don't Run Next to Redis

Our benchmark was the best-case scenario for ElastiCache: same machine, same AZ, sub-millisecond network. We still got 1.76x faster throughput and 4x lower latency.

But in production, your app probably isn't on the same rack as your Redis cluster. Common real-world scenarios:

The Cumulative Impact

Let's do the math for a real application. Say you handle 10,000 requests per second, and each request makes 5 Redis calls. That's 50,000 Redis operations per second.

"Time saved per second" is cumulative latency across all requests. In the cross-region case, you're saving 58 minutes of cumulative wait time every single second. That translates directly to freed-up connections, lower tail latencies, and fewer timeouts.

Why Not Just Use a Local Redis?

You could spin up a local Redis replica in each region. Here's why Cachee is better:

• No replication lag: Cachee's L1 cache is populated from actual traffic. No async replication delay, no stale reads from replica lag.
• No operational overhead: No replica configuration, no failover management, no cross-region networking.
• Write-behind: SETs go to the real cluster in the background. You get strong consistency on reads (cache hit = last written value) without managing write routing.
• Zero code changes: Point your connection string at Cachee. Done. No client library changes, no cluster-aware configuration.
• 100% hit rate: We sustained 100% across 6.28 million requests in our production benchmark. The L1 cache is extremely effective.

Deploying at the Edge

The distance multiplier is most powerful when you deploy Cachee on each application server or in each region:

# Region: eu-west-1 (Redis is in us-east-1)
# Before: Every GET crosses the Atlantic (70ms)
# After:  L1 hit in 16μs, miss forwards to us-east-1

Your EU App Server
    ↓
Cachee Proxy (local, eu-west-1)
    ↓ 16μs hit         ↓ 70ms miss (first access only)
    L1 Cache            ElastiCache (us-east-1)

The first access to a key takes the full cross-region round-trip. Every subsequent access—16 microseconds. With typical key reuse patterns, your effective hit rate approaches 100%.

The Bottom Line

Most caching benchmarks are run in ideal conditions—same machine, same network. Cachee wins even there (1.76x faster, 4x lower latency). But the real story is what happens as distance increases.

Every millisecond of network latency you have to Redis is a millisecond that Cachee eliminates on cache hits. The further away your Redis is, the more dramatic the improvement. At cross-region distances, we're not talking about percentage improvements. We're talking about orders of magnitude.

If your app is further than a millisecond from Redis, the distance multiplier is working against you right now. Cachee turns it into your advantage.