Use Cases Interview Questions

Session store: a STRING or HASH per session id with EXPIRE matching the cookie. HASH lets you HSET lastSeen without rewriting the blob. Losing Redis here logs everyone out, so persistence and replicas are product decisions, not just ops.

Rate limiting: INCR of a window key plus EXPIRE on the first increment is the basic limiter. Sliding windows use ZSET with timestamps as scores and ZREMRANGEBYSCORE. Fixed windows are simpler and burst at boundaries.

Leaderboards: ZSET score is the rank metric; ZREVRANGE gives top-N. Ties need a second score or lexicographic member. Do not rebuild the ZSET from SQL on every read; increment with ZINCRBY.

Distributed lock: SET lock:order NX EX seconds is the basic lock. Release with a Lua compare-and-DEL of the token. Locks without a token DEL are unsafe; any client could drop someone else lock.

Job queue: LIST LPUSH/BRPOP is a simple queue; crashed workers lose the popped job. STREAM plus XREADGROUP and XACK retries pending entries after XAUTOCLAIM. That is why STREAM replaced LIST for serious queues.

GEO: GEOADD plus GEORADIUS or GEOSEARCH for drivers near here. Radius queries on huge sets still scan a geohash range. For nationwide search you shard by region keys, not one global ZSET.

Unique visitors: HyperLogLog PFADD per day; exact uniques if the set fits in a SET. Billing uses SET or a database. HyperLogLog is for dashboards.

Idempotency keys: SET idem:orderId NX EX 86400 around a payment. NX failure means already processed. Combine with the business record; Redis expiry must outlive retries.

Feature flags and config: a HASH of flags with Pub/Sub invalidation. allkeys-lru must not evict this key—use a separate instance or volatile-* only on cache keys. Mixing flag store and cache eviction is an outage.

Dedup of events: SET with NX or Bloom BF.ADD for did we see this event id. Bloom false positives drop events; that may be wrong. For exactly-once, NX on a SET or STRING plus persistence.

Sliding session: GET plus EXPIRE refresh, or HASH plus EXPIRE. Sliding TTL on every request can stampede Redis; refresh only when remaining TTL is below a threshold.

Multi-player presence: Pub/Sub for ticks, SET or ZSET of online user ids with a short TTL refreshed by heartbeat. Expired members leave. Do not trust Pub/Sub as the roster; the SET is the roster.

Fair job scheduling: ZSET score equals run-at timestamp, workers ZRANGEBYSCORE plus ZREM in Lua. Without Lua, two workers grab the same job. This is a classic EVALSHA use case.

Cache of rendered pages: STRING with TTL jitter, cache-aside from origin. Negative cache 404s briefly. Huge HTML values become big keys; compress or fragment.

Redlock caveats: pause-the-process, clock drift, and majority failure modes mean Redlock is not a silver bullet for correctness. For a mutex around a side effect, a single Redis with fencing tokens or an external consensus store may be clearer. Know Kleppmann critique in interviews.

Distributed lock fencing: the lock token is not enough if the holder pauses past EX and another holder starts; the slow holder then writes anyway. A monotonically increasing fencing token checked by the storage layer is the real fix. Redis lock EX only bounds the critical section if the work is short.

Rate limit across Cluster: the counter key must not hot-slot a single {global} tag. Shard by user id. A single global INCR is a Cluster bottleneck.

Inbox and notifications: STREAM per user with MAXLEN approximate, or a LIST of recent ids. STREAM consumer groups if multiple notification workers. Per-user keys need hash tags only when multi-key ops apply.

Geo plus search: Redis GEO does not replace Elasticsearch. Use GEO to shortlist ids then hydrate. Interviewers want that boundary.

When not to use Redis: large relational queries, unbounded datasets that do not fit RAM, and strong multi-key transactions across entities. Redis is memory-first. For those, use a disk database and cache-aside.