Redis System Design

Introduction

System design interviews and real ADRs map requirements to Redis structures and topology — URL shortener (INCR + string), rate limiter (Lua/ZSET), cart (hash), leaderboard (ZSET), notifications (pub/sub or stream), sessions (hash + Cluster).

Always state TTL, eviction, HA mode (Sentinel vs Cluster), consistency tolerance (replica lag), and failure mode (fail open cache miss to DB).

Redis is rarely the whole architecture — pair with PostgreSQL source of truth and Kafka events.

Understanding the topic

Key concepts

• URL shortener — INCR counter + SET blob.
• Rate limit — sliding ZSET or Lua fixed window.
• Cart — hash fields per SKU qty.
• Leaderboard — ZSET scores.
• Feed — ZSET timeline + fan-out.
• Notification — pub/sub live, stream durable.

flowchart TB
  subgraph patterns [Common patterns]
    U[URL INCR+SET]
    R[Rate limit Lua]
    C[Cart Hash]
    L[Leaderboard ZSET]
  end
  patterns --> Topology[Sentinel or Cluster]
  Topology --> Ops[TTL eviction monitoring]

Step-by-step explanation

1. Clarify read/write QPS and data size.
2. Pick Redis types per access pattern.
3. Choose single node + Sentinel vs Cluster.
4. Define TTL, invalidation, persistence tier.
5. Document failure and staleness behavior.
6. Size memory from key count × bytes sample.

Syntax reference

Common commands

• State HA and persistence in design doc.
• Estimate memory: keys × MEMORY USAGE sample.
• Hot path commands only O(1) or O(log N).

# URL shortener core
id = INCR counter:url
SET url:{id} "https://long..." EX 31536000

# Leaderboard
ZINCRBY game:lb 100 player:42
ZREVRANGE game:lb 0 9 WITHSCORES

Informative example

Design sketch — API cache + rate limit + session in one microservice:

# Session (hash, 30m TTL)
HSET session:{id} userId 42 roles admin

# Rate limit (100/min)
# Lua script on rl:{userId}

# Product cache (string JSON, 1h TTL jitter)
SET catalog:sku42 "{...}" EX 3600

Draw topology: Spring Boot pods → Redis Cluster 6 nodes, allkeys-lru, replica reads for catalog only, sessions on master for consistency.

Real-world use

Real-world use cases

• Interview: design Twitter timeline.
• Interview: design Uber nearby drivers.
• ADR: session migration to Redis Cluster.
• Capacity plan new marketplace launch.
• Choose pub/sub vs stream for notifications.

Best practices

• Explicit staleness SLO per feature.
• Hash tags for multi-key session patterns in Cluster.
• Separate logical DB or key prefix per domain.
• Failure: cache miss degrades to DB gracefully.
• Size with --bigkeys sample load test.
• Security: ACL, TLS, no public Redis.

Common mistakes

• Redis as only database for orders.
• No TTL in design doc.
• Undersized Cluster one hot slot.
• Ignoring replica lag in read design.

Advanced interview questions

Summary

Map each feature to Redis type + TTL.