A-12 — Multi-Region Redis: Active-Active and Geo-Replication

Counter Convergence

For INCR/DECR, CRDTs sum all increments from all regions:

US: INCRBY inventory 100
EU: INCRBY inventory 50
APAC: DECRBY inventory 30
→ Convergent value: 100 + 50 - 30 = 120 (regardless of order or timing)

This is the correct semantics for distributed counters — page views, inventory adjustments, score increments.

Set Merge Semantics

For Sets, the CRDT merges all adds and respects the "observed-remove" rule — a delete only removes adds that the deleting replica has observed:

US: SADD tags "redis"       → {redis}
EU: SADD tags "postgres"    → {postgres}
(changes propagate)
Final: {redis, postgres}    ← union
 
US: SREM tags "redis"       → removes the "redis" add that US observed
EU: SADD tags "redis"       → adds "redis" again simultaneously
(changes propagate)
Final: {redis, postgres}    ← EU's add survives because US only removed its own add

This can produce unintuitive results (deletes don't propagate as expected), but it ensures convergence.

---

Redis Enterprise vs Redis OSS for Active-Active

Open-source Redis does not natively support active-active geo-replication. The replication system is designed for primary-replica, not peer-to-peer.

Redis Enterprise (commercial product from Redis Ltd.) provides:

• Active-Active geo-distribution with CRDT semantics
• Automatic conflict resolution
• Global keyspace — all regions share the same logical database
• WAN-optimised replication (delta compression, bandwidth throttling)

Redis Cloud (managed Redis Enterprise) is the SaaS offering.

Alternatives for OSS Redis:

• Roshi (SoundCloud's approach): application-layer CRDT using Sorted Sets with timestamp scores; reads perform a merge of multiple region results
• Application-level coordination: accept that writes go to one authoritative region and reads may be stale in other regions
• Consistent hashing + per-region primary: different keys are "owned" by different regions; cross-region reads accept the latency

---

The Consistency Trade-off

Active-active replication is eventually consistent. Between when a write is applied in one region and when it propagates to all others (100–300ms for cross-region), different users see different values:

US user writes: SET username:1001 "Jatin"
150ms later, EU user reads: GET username:1001
→ EU replica: "OldName"  (replication hasn't arrived yet)

For some use cases this is acceptable:

• Product recommendations (briefly stale is fine)
• Feature flags (a user in EU and a user in US seeing different states for 200ms is acceptable)
• Leaderboards (eventual consistency is expected)

For some it is not:

• Account balances (EU and US must agree on the balance)
• Inventory counts (two regions cannot both sell the last item)
• Sessions (a session created in the US must be immediately valid in EU)

For strong consistency across regions: use a database with cross-region transactions (CockroachDB, Spanner, YugabyteDB), not Redis.

---

Practical Patterns for Multi-Region Redis Without Active-Active

Regional Primary with Global Read Replicas

// Each region has its own Redis primary for local writes
// Plus read replicas of all other regions' primaries
 
// When user writes (US user):
await usRedis.set(`user:${id}:profile`, data);
 
// When user reads in EU (accept small lag):
const profile = await euRedis.get(`user:${id}:profile`);
// Falls back to US primary if EU replica hasn't received the write
if (!profile) {
  const profileFromUS = await usRedis.get(`user:${id}:profile`);
  return profileFromUS;
}

Sticky Sessions by Region

Route each user's requests to their "home region" for consistent reads and writes. Use geolocation at the CDN/load balancer layer:

US users → us-east-1 Redis (reads and writes)
EU users → eu-west-1 Redis (reads and writes)
# Cross-region migration: replicate with lag; brief inconsistency on region change

Read-Your-Own-Writes via Sticky Routing

After a write, route subsequent reads to the same region (where the write is definitely present) for the next few seconds:

async function write(key: string, value: string, userId: string) {
  await redis.set(key, value);
  // Tag this user as "just wrote" for 5 seconds
  await redis.set(`write-tag:${userId}`, '1', 'EX', 5);
}
 
async function read(key: string, userId: string) {
  const justWrote = await redis.exists(`write-tag:${userId}`);
  if (justWrote) {
    // Route to primary to read our own write
    return primaryRedis.get(key);
  }
  // Route to local replica (possibly stale, but user hasn't written recently)
  return localReplicaRedis.get(key);
}

---

Summary

• Active-passive: one primary region, read replicas in other regions — low write latency only in the primary region
• Active-active: every region writes locally — requires CRDT conflict resolution; supported by Redis Enterprise/Cloud, not OSS Redis
• CRDTs resolve conflicts via: LWW for Strings, sum-all-increments for counters, merge for Sets, field-level LWW for Hashes
• Active-active is eventually consistent — writes propagate with 100–300ms cross-region lag
• Do not use Redis active-active for strong consistency requirements (account balances, inventory) — use a transactional database
• OSS Redis alternatives: regional primaries + cross-region read replicas, sticky user routing, application-layer CRDT patterns
• The question "should I use multi-region Redis?" often has the answer "no" — regional cache with fallback is simpler and correct for most use cases

Next: A-13 — Disaster Recovery, Backup, and Point-in-Time Restore — RDB backup scheduling, AOF log shipping, recovery runbooks, and testing restore procedures before you need them.

---