← Blogs

Redis Interview Notes

Sorted Sets (ZSET)

A sorted set maps each unique member to a score and orders members by score. Range queries and updates are typically O(log N).

Compact Encoding

Small sorted sets can use a compact listpack representation. Redis converts to its general representation when the set exceeds limits such as zset-max-listpack-entries or zset-max-listpack-value. Older Redis versions used a ziplist and correspondingly named settings. Check the settings for the version you run.

Skip List and Hash Table

The general representation combines a skip list for score-ordered operations with a hash table for looking up a member’s score. The skip list uses multiple levels of forward links, making insertion, deletion, and range traversal efficient. Compared with a balanced tree, its ordered traversal is straightforward.

Reference: Redis memory optimization.

Multilevel Caching

A common read path uses a local cache such as Caffeine, a shared Redis cache, and then the database. Each layer offers a different latency, capacity, and consistency tradeoff. Invalidation has to account for both the local and shared layers.

Redis Transactions

  • MULTI starts queuing commands.
  • EXEC runs the queued commands without another client’s commands interleaving.
  • DISCARD drops the queued commands.
  • WATCH makes EXEC conditional on watched keys remaining unchanged, providing optimistic concurrency control.

Redis transactions do not roll back commands that have already executed. Their commands execute sequentially as one isolated operation with respect to other clients, but Redis does not provide SQL-style selectable isolation levels.

1
2
3
4

WATCH balance
MULTI
DECRBY balance 100
EXEC

If another client changes balance before EXEC, the transaction aborts. See the Redis transaction documentation.

Consistency with a Database

Cache invalidation after a database update is common, but the database write and Redis operation are not atomic by default. Delayed double deletion or change-data capture from a database binlog (for example through Canal or Debezium) can reduce stale entries, depending on the application’s consistency requirements.

Redis replication is asynchronous, so replicas can lag and a failover can lose recently acknowledged writes. Redis Cluster distributes data and shares topology through gossip; it does not provide strong consistency.

Memory Pressure

Configure maxmemory and choose a policy appropriate to the workload:

  • allkeys-lru: Evict approximately least-recently-used keys from all keys.
  • volatile-lru: Choose only among keys with an expiration.
  • volatile-ttl: Prefer keys with the shortest remaining TTL.
  • allkeys-lfu: Prefer less-frequently-used keys.
  • noeviction: Reject writes that would exceed the limit rather than evicting data.

Redis also removes expired keys lazily when they are accessed and actively samples expiring keys in the background. For a very large key, UNLINK can free memory asynchronously instead of making DEL do all the work on the command path. See key eviction.

Atomic Operations

Commands such as SET ... NX, INCR, and DECR are atomic as individual operations. MULTI/EXEC groups commands without interleaving; WATCH adds an optimistic check. Lua scripts are useful when several operations must run atomically together.

Large Keys

There is no universal byte or element count that defines a “big key.” A large string or a collection with many entries can cause long command execution, large network transfers, or slow deletion. The relevant threshold depends on latency and memory goals.

  • redis-cli --bigkeys scans to report the largest key found for each data type.
  • SCAN can locate keys incrementally; commands such as STRLEN and HLEN help inspect their size.
  • An RDB analysis tool can inspect a snapshot offline.

Split oversized collections when their access pattern allows it, and consider UNLINK when deleting them.

Why Redis Is Fast

Redis keeps its working data in memory and uses efficient data structures. Its event loop multiplexes many client connections. Command execution is primarily single-threaded, which avoids locking around ordinary data operations; supported Redis versions can use I/O threads for some network work. Progressive rehashing and compact encodings reduce pauses and memory use in suitable cases.