---
title: "Last Mile Redis"
description: "Last Mile Redis presents a globally distributed caching design aimed at keeping backend responses under the 100-millisecond threshold by placing Redis near users. It argues that regional datasets overlap less than expected, making one Redis server per region a practical alternative to centralized sharding. The design combines standalone regional caches with a Dallas primary Redis and writable replicas configured with replica-read-only no, allowing local writes while replication distributes global changes. A DEL issued at the primary can therefore purge bad cache data across regions, while timestamped keys and expiration handle ordinary freshness; the same mechanism can also broadcast content or fan out queue messages."
---

# Last Mile Redis

[Fly.io](https://yomu.fyi/company/fly-io) · Jul 16, 2021

**Type:** Problem & solution

## Summary

Last Mile Redis presents a globally distributed caching design aimed at keeping backend responses under the 100-millisecond threshold by placing Redis near users. It argues that regional datasets overlap less than expected, making one Redis server per region a practical alternative to centralized sharding. The design combines standalone regional caches with a Dallas primary Redis and writable replicas configured with replica-read-only no, allowing local writes while replication distributes global changes. A DEL issued at the primary can therefore purge bad cache data across regions, while timestamped keys and expiration handle ordinary freshness; the same mechanism can also broadcast content or fan out queue messages.

## Context

Backend applications often need to reduce request latency, and database optimization is painful; caching can remove tens of milliseconds from queries. The post argues that placing cached data close to end users can save hundreds of milliseconds compared with routing requests to a distant centralized server, while regional data usually overlaps relatively little.

## Approach / What changed

Run Redis and application servers in multiple geographic regions, using one independent cache per region. Configure a Dallas Redis as the primary and regional replicas with replica-read-only no, so replicas accept local writes while continuing to receive replicated changes. Use key-based invalidation, primary-issued DEL commands, global SET operations, and Redis lists with LPUSH and BRPOP for propagation and fan-out.

## Takeaways

- Geographic cache locality means regional datasets often have limited overlap, so one Redis instance per region can avoid explicit application sharding.
- Setting replica-read-only no lets regional Redis replicas accept local writes while continuing to sync changes from a primary.
- Deleting a bad key on the primary propagates through replicas for an “instant” global purge; the design also supports global SET values and list-based fan-out with LPUSH and BRPOP.

**Tags:** [Caching](https://yomu.fyi/topic/caching), [Distributed Systems](https://yomu.fyi/topic/distributed-systems), [Redis](https://yomu.fyi/topic/redis), [Replication](https://yomu.fyi/topic/replication)

- Source: [Fly.io](https://fly.io/blog/last-mile-redis)
- Source URL: https://fly.io/blog/last-mile-redis
- Ingested by Yomu: 2026-09-02T11:59:49.686Z

[Read original post](https://fly.io/blog/last-mile-redis)