Redis as a Database: Structures, Persistence and Limits

In one line

Redis is an in-memory data-structure server: strings, hashes, lists, sets, sorted sets, streams, bitmaps and HyperLogLog, each with atomic commands. Persistence (RDB snapshots, AOF) and replication make it durable enough for many uses, but memory cost, asynchronous replication and eviction mean it's usually a cache or a store for ephemeral and derived data, not the only copy of critical records.

0/7 · 0%

Think of it like this

A whiteboard in the office. Instant to read and update and great for today's rota and scores, but everything must fit on the board, and a wipe loses whatever wasn't also written in the ledger.

Key ideas

01
Pick the structure for the access pattern: sorted sets for leaderboards and time-ordered feeds, hashes for objects and carts, sets for membership, streams for event logs with consumer groups, bitmaps and HyperLogLog for compact counting, strings with INCR for counters and rate limits.
02
Durability: RDB snapshots (compact, can lose minutes), AOF with appendfsync everysec (lose up to ~1 s), both combined in practice. Replication is asynchronous, so failover can lose acknowledged writes; WAIT only reduces the window.
03
Scale: Redis Cluster splits keys across 16,384 hash slots; multi-key operations need keys in one slot (hash tags {user:42}). Watch big keys (a 5M-member set blocks the event loop on DEL; use UNLINK) and hot keys.
04
Good as a database for: sessions, carts, rate limits, leaderboards, presence, counters, recent-items lists, and queues where loss is tolerable or rebuildable. Keep money, orders and anything auditable in a durable database, with Redis as a cache or derived view.
05
The Redis course covers every structure, caching patterns, Lua, Cluster, Sentinel and failure modes in depth.

Code & diagrams

redis-designs.redisbash

# leaderboard
ZINCRBY lb:weekly 50 user:42
ZREVRANGE lb:weekly 0 9 WITHSCORES
ZREVRANK lb:weekly user:42

# shopping cart as a hash with TTL
HSET cart:user:42 sku:TSHIRT-M 2 sku:CAP-BLUE 1
EXPIRE cart:user:42 604800

# online presence: set with per-user heartbeat keys
SET presence:user:42 1 EX 60
# recent items (capped list)
LPUSH recent:user:42 product:991
LTRIM recent:user:42 0 49

# fixed-window rate limit
INCR rl:user:42:202609141015
EXPIRE rl:user:42:202609141015 60

Interview problem

The problem

Can Redis be the only store for a shopping cart?

The team wants carts only in Redis (no database). Carts matter for conversion; a lost cart costs sales but not money. Decide, and design durability and failure behaviour.

When it breaks

maxmemory reached with an eviction policy on a store (not a cache)

What you see

With allkeys-lru, Redis silently evicts sessions and carts; with noeviction, writes fail with OOM errors.

Fix & prevent

Size memory with headroom, use noeviction for data you can't lose and alert on memory use, and separate cache and store workloads into different instances.

Explain it without notes

Why is Redis replication a concern for durability?

Practice

Pick a Redis structure for: unique daily visitors (approximate), a job queue with acknowledgements, a top-100 leaderboard.

Trade-offs

↔
Microsecond latency and rich atomic structures, bounded by RAM cost and weaker durability than a disk-first database.

Done when you can

I can choose Redis structures for common designs and decide when Redis may be a primary store.

Command Palette