Redis - System Design Guide

Overview

Redis is an in-memory data structure server. Beyond simple strings, it offers hashes, lists, sets, sorted sets, streams, bitmaps, HyperLogLog, and geospatial indexes, each with atomic operations. Because data lives in memory and commands execute on a single thread per shard, typical operations complete in well under a millisecond.

Redis is used as a cache, session store, rate limiter, leaderboard, distributed lock service, pub/sub bus, and lightweight queue. It supports persistence (RDB snapshots and AOF logs), replication with automatic failover (Sentinel), and horizontal scaling with Redis Cluster (16,384 hash slots).

A whiteboard next to your desk

Anything on the whiteboard is instantly visible, and it supports lists, tallies, and rankings. It is small compared with the filing cabinet (database), and if nobody takes a photo (persistence), it can be wiped.

When to use it

Caching hot data in front of a database.
Sessions, rate limits, counters, and feature flags.
Leaderboards and rankings (sorted sets).
Real-time features: pub/sub, streams, presence.
Short-lived coordination: locks, deduplication.

Where it shows up in interviews

Leaderboards

Recognize it when: top N players, ranks, scores.

Design a gaming leaderboard
Design trending posts

Rate limiting and counters

Recognize it when: per-user limits, view counts.

Design a rate limiter
Design a view counter

Caching layer

Recognize it when: reduce DB load and latency.

Design a news feed cache
Design a product catalog

Where it is used in real software

Twitter timelines

Twitter historically cached home timelines in Redis lists for fast fan-out reads.

GitHub, Stack Overflow, Shopify

Use Redis for caching, queues (Sidekiq), and rate limiting.

Managed Redis

Amazon ElastiCache, Azure Cache for Redis, and Valkey (the open-source fork) are widely used.

Key terms

Sorted set (ZSET): Members ordered by score; O(log n) insert and rank queries.
TTL: Automatic key expiry.
Pipeline / Lua script: Batch commands, or run atomic multi-step logic on the server.
RDB / AOF: Snapshot persistence / append-only command log.
Redis Cluster: Shards keys over 16,384 hash slots with replicas.

How it works, step by step

1
Pick the data structure
String for values and counters, hash for objects, ZSET for rankings, list/stream for queues.
2
Design keys
Namespaced keys like user:42:profile; set TTLs.
3
Use atomic commands
INCR, HINCRBY, ZADD, SETNX avoid race conditions.
4
Choose persistence
None for pure caches, AOF for durability-sensitive uses.
5
Scale and protect
Replicas for failover, Cluster for sharding, memory limits with an eviction policy.

Redis data structures and use cases

Choose the structure, get atomic operations for free

Structure	Example command	Use case
String	INCR likes:post:9	Counters, cached JSON
Hash	HSET user:42 name Ana	Object fields
Sorted set	ZADD board 1500 ana	Leaderboards, time-ordered feeds
List / Stream	XADD events * type click	Queues, event logs
Set	SADD online user:42	Unique members, tags
HyperLogLog	PFADD uniques user:42	Approximate unique counts in 12 KB
Geo	GEOADD drivers -122.4 37.7 d1	Nearby search

NOWStructure: String | Example command: INCR likes:post:9 | Use case: Counters, cached JSON

Many features that would need complex SQL become one or two Redis commands.

Implementation

1// Game leaderboard with sorted sets2await redis.zIncrBy("leaderboard:2026-09", 50, "player:ana");       // add points3const top10 = await redis.zRangeWithScores("leaderboard:2026-09", 0, 9, { REV: true });4const rank = await redis.zRevRank("leaderboard:2026-09", "player:ana"); // 0-based5 6// Players around Ana (for 'you are #1,234' views)7const around = await redis.zRange("leaderboard:2026-09", Math.max(0, rank! - 2), rank! + 2, { REV: true });

Complexity and performance

GET / SET / INCRO(1)

Sub-millisecond.

ZADD / ZRANKO(log n)

Skip list.

Throughput~100k+ ops/s per shard

More with pipelining.

Trade-offs

Speed vs durability

In-memory speed comes with a risk of losing recent writes on crash unless AOF with fsync is used.

Memory cost

RAM is expensive; keep only hot or small data and set eviction policies.

Variants and related techniques

Redis Streams

Log-based messaging with consumer groups, a lightweight alternative to Kafka for modest volumes.

Redis modules

Search (RediSearch), JSON, and time series extend Redis.

Common mistakes

KEYS * in production.
Fix: It blocks the server; use SCAN.
Huge keys or collections.
Fix: A single big key cannot be sharded and slows commands; split it.
Relying on Redis locks for strict correctness.
Fix: Use fencing tokens or a consensus system for critical mutual exclusion.

Interview questions

How would you build a real-time leaderboard?

A Redis sorted set per leaderboard: ZINCRBY to update scores, ZREVRANGE for the top N, ZREVRANK for a player's rank. Partition by time period and persist periodically to a database.

Why is Redis fast even though it is single-threaded?

Data is in memory, operations are simple and O(1) or O(log n), there is no locking overhead, and I/O is multiplexed with an event loop. Redis 6+ also uses threads for network I/O.

Practice problems

Problem	Difficulty	What it trains
Implement a rate limiter with INCR and EXPIRE	Easy	Atomic counters.
Design a real-time leaderboard for 10M players	Medium	Sorted sets and sharding.
Design presence (who is online) for a chat app	Medium	Sets with TTLs.