Redis, by the shape of the value

Cache-aside, and the four ways it breaks

The application, not the cache, owns the logic. On a read, look in Redis first; on a miss, read the database, write the value back with a lifetime, and return it. On a write, update the database, then delete the cached key rather than overwriting it.

Deleting rather than overwriting on a write matters because two concurrent writers can otherwise interleave their read of the database and their write to the cache, leaving the cache holding the older of the two values permanently. Deletion makes the next reader repopulate from the database instead.

Failure one: stampede on a hot key

A popular key expires and every in-flight request misses at the same instant, so the database receives thousands of identical queries. Fix by letting exactly one request recompute: each misser attempts SET lock:user:42 token NX PX 5000, the single winner queries the database and repopulates, and the losers either wait briefly and re-read or serve the previous value. An alternative that avoids the lock entirely is to store the value with a logical freshness timestamp and let a request refresh it probabilistically as it approaches expiry, so refreshes are spread out in time rather than synchronized.

Failure two: mass expiry, a synchronized wave of misses

Populating ten thousand keys in one batch with an identical lifetime makes all ten thousand expire in the same second. Add randomness to every lifetime, for example a base of 300 seconds plus a random 0 to 60, so expiry is spread across a minute.

Failure three: lookups for things that do not exist

Requests for identifiers that have no row miss the cache every time and always reach the database, which is also the shape of an easy denial of service attack. Cache the absence itself as a sentinel value with a short lifetime, or keep a Bloom filter of known identifiers and reject unknown ones before touching the database.

Failure four: one key hotter than one node

Sharding does not help when a single key takes the traffic, because a key lives on exactly one node. Three remedies, in the order you should offer them: a short-lived in-process cache in the application layer, which absorbs most reads and is bounded by its own lifetime; splitting the key into a small number of copies with a suffix so readers choose one at random and spread the load; and read replicas, if serving a slightly stale value is acceptable.

Rate limiting, three designs and the tradeoff between them

Rate limiting is the most common Redis question in a system design loop because it exercises expiry, atomicity, and a real accuracy versus memory tradeoff.

Design A, fixed window counter

The key embeds the window, so the window rolls over by key naming alone.

INCR rl:user:42:2026-08-15T14:23        # returns the new count
EXPIRE rl:user:42:2026-08-15T14:23 120  # only needed when the count came back as 1

One small key per user per window, constant time, trivially correct under concurrency because the increment is atomic. Its flaw is the boundary: a caller who spends the full allowance at the end of one minute and again at the start of the next has sent twice the limit inside a two second span. Offer this first, name the flaw, and let the interviewer decide whether it matters.

Design B, sliding window log with a sorted set

Exact enforcement over a continuously moving window. The member is a unique request identifier and the score is the arrival time in milliseconds. All four steps run in one script so that concurrent requests cannot both pass the check.

-- KEYS[1] = rl:user:42   ARGV = now_ms, window_ms, limit, request_id
redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, ARGV[1] - ARGV[2])
local used = redis.call('ZCARD', KEYS[1])
if used < tonumber(ARGV[3]) then
  redis.call('ZADD', KEYS[1], ARGV[1], ARGV[4])
  redis.call('PEXPIRE', KEYS[1], ARGV[2])
  return 1
end
return 0

Walked through completely, with a limit of 5 requests per 60,000 milliseconds on the key rl:user:42. Every step shows the full contents of the sorted set after the step runs.

Cost: memory proportional to the limit per active caller, because every admitted request is stored for the length of the window. A limit of 1,000 per minute across a million active users is a billion members, which is the moment to switch designs.

Design C, token bucket in a hash

Constant memory per caller regardless of the limit, and it permits a controlled burst. Two fields hold the state: tokens remaining and the time of the last refill. On each request a script computes how many tokens have accrued since the last refill, caps that at the bucket capacity, and spends one if any remain.

-- KEYS[1] = tb:user:42   ARGV = now_ms, refill_per_ms, capacity, cost
local s = redis.call('HMGET', KEYS[1], 'tokens', 'ts')
local tokens = tonumber(s[1]) or tonumber(ARGV[3])
local ts = tonumber(s[2]) or tonumber(ARGV[1])
tokens = math.min(tonumber(ARGV[3]), tokens + (ARGV[1] - ts) * ARGV[2])
if tokens >= tonumber(ARGV[4]) then
  redis.call('HSET', KEYS[1], 'tokens', tokens - ARGV[4], 'ts', ARGV[1])
  redis.call('PEXPIRE', KEYS[1], 60000)
  return 1
end
redis.call('HSET', KEYS[1], 'tokens', tokens, 'ts', ARGV[1])
return 0

Matchmaking pool, two sorted sets over one member set

The pattern worth stealing from this one is not the game, it is the shape: when a workload needs two orderings over the same population, you keep two sorted sets over one member set, because a sorted set carries exactly one score. A matchmaker picks whom to build a match around by longest wait, then searches for opponents by skill rating. Those are two different axes over the same players, so neither one set nor a single composite score can serve both.

The keys

The search, and why the window widens

Each tick reads the anchor from the time set, derives a rating window from how long that anchor has waited, and reads the window out of the rating set. Only steps 1 and 4 and 6 are Redis calls; the rest is arithmetic, and saying so is what stops the trace sounding like magic.

# 1. the anchor. 0 0 are POSITIONS, not scores: no BYSCORE here
ZRANGE mm:enq:na:ranked 0 0 WITHSCORES   -> p:9182, 1755530400000
# 2. w = now - that score = 5000 ms  (arithmetic)
# 3. window = 50 + 25 * floor(w / 5000) = 75, capped at 400
ZSCORE mm:pool:na:ranked p:9182            -> "1450", the anchor's rating
# 5. bounds = 1450 +/- 75  (arithmetic)
# 6. same command name, different key, different axis: these ARE scores
ZRANGE mm:pool:na:ranked 1375 1525 BYSCORE LIMIT 0 50 WITHSCORES

Anchor on wait, search on the other axis. Sweeping the rating axis alone starves whoever sits at a sparse part of the curve. Anchoring on the oldest member puts a ceiling on wait time, and widening the window with age is what pays for that ceiling. The same shape works for any "match these two populations, but do not let anyone starve" problem.

The claim has to be one script

Reading candidates and removing them are two round trips, and in the gap another worker or a cancel can take one. Put the check and the removal in one script and the gap closes with no lock:

-- KEYS[1] = the rating set, KEYS[2] = the time set, ARGV = candidate ids
for i = 1, #ARGV do
  if redis.call('ZSCORE', KEYS[1], ARGV[i]) == false then return 0 end
end
redis.call('ZREM', KEYS[1], unpack(ARGV))
redis.call('ZREM', KEYS[2], unpack(ARGV))
return #ARGV

The property to name out loud: there is no rollback path to write, because a partial claim is not reachable. The script either finds every member present and removes them all, or finds one missing and removes nothing. A cancel is the same shape, so Redis serializes cancel against claim for free, and the design work moves to what the losing side is told: a cancel that removes zero members means a match already exists, so answer 409 with the match identifier rather than a bare failure.

Many workers: partition, lease, fence

Shard on region:mode, so two workers never touch the same keys. Do not shard on the score axis you search: a rating band boundary is a wall the widening window can never cross, so someone just under a boundary waits forever while a fine opponent sits just above it. Region and mode are product walls; a rating wall is an artifact of your sharding scheme.

SET mm:lease:na:ranked worker-3 NX PX 10000  # renew at ~1/3 of the TTL
INCR mm:fence:na:ranked                      -> 41, this owner's token
-- inside the claim script, before anything is removed
if redis.call('GET', KEYS[3]) ~= ARGV[1] then return -1 end

Five more things a sorted set score can mean

A filter applied to a ranking. Combining a board with a set of identifiers narrows it, because a set contributes a score of one per member, so weighting that side at zero preserves the original points.

ZINTERSTORE lb:friends:u42 2 lb:global friends:u42 WEIGHTS 1 0
ZRANGE lb:friends:u42 0 9 REV WITHSCORES   -> a friends-only leaderboard

Last touched, which gives deduplication a list cannot. Viewing an item twice appends twice to a list. Here the member is the item and the score is the time, so a repeat view moves it instead of duplicating it, and trimming is by rank.

ZADD rv:u42 1755205200 item:991        -- a second view just updates the score
ZREMRANGEBYRANK rv:u42 0 -21           -- keep only the 20 newest
ZRANGE rv:u42 0 19 REV                 -> recently viewed, newest first

Nothing at all, so ordering falls to the member itself. Give every member the same score and the set sorts lexicographically, which turns a range query into a prefix scan for typeahead.

ZADD terms 0 banana 0 band 0 bandana 0 bank 0 cactus
ZRANGE terms "[ban" "[ban\xff" BYLEX     -> banana, band, bandana, bank

An attribute value, making the set a secondary index. Redis cannot search by anything but the key, so an index you maintain yourself is the only way to ask for a price band. The same shape gives stable pagination, since paging by an exclusive score bound does not shift when rows are inserted, the way an offset does.

ZADD idx:price 2499 sku:88 1899 sku:91 3200 sku:14
ZRANGE idx:price 1800 2600 BYSCORE       -> sku:91, sku:88
ZRANGE feed:u42 (1755205200 -inf BYSCORE REV LIMIT 0 20
-- the page after the item scored 1755205200, the parenthesis makes the bound exclusive

Popularity that fades. Events raise the score and a periodic job multiplies every score down at once, so trending decays with no per-item bookkeeping and no background timer per entry.

ZINCRBY trending 1 post:551              -- on each view
ZUNIONSTORE trending 1 trending WEIGHTS 0.9   -- every 10 minutes, decay all
ZREMRANGEBYSCORE trending -inf 0.5     -- drop what has faded out