DBRaven
Start Review →
Architecture Evolution Path

Single Cache Layer → Distributed Cache

Medium

Evolving from a single Redis node (or small cluster) to a distributed cache topology using consistent hashing, enabling horizontal memory scaling, geographic distribution, and cache isolation between workload types: at the cost of increased operational complexity and potential hotspot concentration.

Topology Changes

Architecture Diff
+3 added
Single Redis Node / Sentinel Cluster
→
Distributed Redis Cluster (Consistent Hash Ring)3 changes
Unchanged
Added
Removed
Modified

From

Single Redis Node / Sentinel Cluster

→
4 mutations

To

Distributed Redis Cluster (Consistent Hash Ring)

Topology Mutations

Component AddedRedis Cluster Shards (N nodes)

Single Redis node replaced by 3-6 primary shards each with a replica

Operational Impact

Consistent hash ring distributes keys across shards; adding/removing a node requires key migration (~15-30% of keys rehash)

Routing Layer AddedConsistent Hash Router (Client-side)

Client library routes each cache key to the correct shard using consistent hashing

Operational Impact

MGET and pipelines that span multiple keys may hit multiple shards: multi-key commands require client-side scatter-gather

Dependency AddedCluster Health Monitor

Redis Cluster status monitoring required: CLUSTERINFO, connected nodes, slot migration status

Operational Impact

Node failure triggers automatic failover to replica; failover window ~10-30s during which those keys miss

Component AddedCache Isolation Shards (Optional)

Dedicated shards for high-priority workloads (session cache isolated from product cache)

Operational Impact

Session cache eviction no longer triggered by product catalog warm-ups; memory allocation is explicit per shard

Migration Stages

1
Key Pattern Analysis1 week

Analyze existing cache key patterns and sizes. Map key namespaces to expected shard assignments. Identify multi-key operations (MGET, pipelines) that will require scatter-gather after sharding.

Low risk·Rollback possible
2
Redis Cluster Provisioning1-2 weeks

Deploy Redis Cluster with 3 primary shards and 3 replicas minimum. Configure memory limits per shard. Verify cluster topology via CLUSTER INFO. Set up cluster health monitoring and alerting.

Low risk·Rollback possible
3
Application Client Update1-3 weeks

Update application to use cluster-aware Redis client. Test all cache operations including multi-key commands (MGET, MSET, pipelines). Update MGET to scatter-gather pattern if keys span multiple shards.

Medium risk·Rollback possible
4
Traffic Migration1-2 weeks

Gradually migrate cache writes from single node to cluster. Accept cold-start miss rate increase as cluster warms up. Monitor hit rate recovery.

Medium risk·Rollback possible
5
Single Node Decommission1 week

Drain remaining traffic from single node. Verify cluster hit rate matches pre-migration single-node hit rate. Decommission single node.

Low risk·No rollback after this stage

Migration Risks

operationalWarning

Adding or removing cluster nodes causes consistent hash ring rebalancing: temporary cache miss spike

Mitigation

Schedule node additions during low-traffic windows; pre-warm new nodes with key migration before announcing to clients

couplingWarning

Multi-key operations (MGET) cannot span shards in a single command: requires client-side scatter-gather

Mitigation

Audit all MGET, MSET, and pipeline operations before migration; implement scatter-gather in application code

operationalInfo

Cluster slot migration during rebalancing causes temporary key unavailability (MOVED error)

Mitigation

Client library handles MOVED errors automatically with retry; verify client library cluster support before migration

Coupling Changes

operational couplingIncreases

Cluster topology changes (node add/remove) require coordinated slot migration

Consequence

Cache capacity changes are no longer zero-touch: require planned migration windows

memory couplingDecreases

Workload memory isolation prevents one workload from evicting another's hot keys

Consequence

Session cache hit rate is stable even during product catalog warm-up spikes

Consistency Model Changes

  • ·Single-node Redis was not strongly consistent across replicas: cluster replication is also asynchronous
  • ·Node failover introduces a brief window where keys on the failed primary shard are unavailable
  • ·Cluster remains available during single-node failure: only the affected key slot range is impacted

Rollback Risks

  • ·Application client library changes require code rollback: cannot be reversed without a deployment
  • ·Cache keys written to cluster after single-node decommission have no fallback
  • ·Cluster-mode MGET scatter-gather cannot be rolled back without restoring scatter-gather code