Redis Skills Assessment

Redis Sorted Sets are purpose-built for ranked data: each member has an associated floating-point score, Redis automatically maintains the sort order, and rank queries (ZRANK, ZREVRANK) and range retrievals (ZRANGE, ZREVRANGE) run in O(log N). Adding or updating a player's score (ZADD) is O(log N). This makes leaderboards the canonical Sorted Set use case. Hashes store structured data per player but provide no ordering. Lists maintain insertion order, not score order. Sorting in application code requires loading the entire dataset into memory.

A cache without TTLs and without an eviction policy is a memory leak by design. Two complementary mechanisms prevent this: TTLs (EXPIRE command or EX option on SET) ensure individual keys expire automatically after a defined period. The maxmemory-policy configuration controls what Redis does when maxmemory is reached - allkeys-lru evicts the least recently used keys across all keyspaces, making Redis self-managing under memory pressure. For a cache, allkeys-lru or allkeys-lfu (least frequently used) are the correct eviction policies. Simply adding memory (option D) is a temporary fix that defers the problem.

Redis solves the distributed rate limiting problem because it is a single, centralized data store that all 10 instances can access atomically. The INCR command is atomic in Redis - incrementing a counter is a single operation with no race conditions, unlike application-level counters that require locking. A common pattern is: INCR user:{id}:requests, SET EXPIRE to 60 seconds on first increment. If the count exceeds 100, reject the request. All 10 instances share the same counter, enforcing a true global rate limit. Pub/Sub (option A) broadcasts events but does not provide atomic counting with consistent state.

Redis Cluster partitions data across nodes using 16,384 hash slots. Each key is assigned to a hash slot using CRC16, and hash slots are distributed across nodes. This allows the cluster to scale horizontally - with 64GB nodes and 500GB of data, approximately 8 nodes are needed. The key trade-off is that commands operating on multiple keys (like MGET, MSET, or transactions with MULTI/EXEC) only work atomically if all involved keys hash to the same slot. This is managed using hash tags ({user}) to force related keys to the same slot. Redis Cluster does not provide cross-node ACID transactions.

AOF with appendfsync everysec is the correct balance for session data: every write operation is appended to the AOF log, and the log is flushed to disk at most once per second, meaning at most 1 second of sessions can be lost on a crash. On restart, Redis replays the AOF to reconstruct the full session dataset. RDB snapshots (option C) at 60-second intervals could lose up to 60 seconds of session writes - a significant number of new login events. AOF provides much finer durability granularity. appendfsync always (per-command flush) maximizes durability at the cost of write throughput.

False. Redis supports two persistence mechanisms: RDB (Redis Database) snapshots, which save a point-in-time snapshot of all data to disk at configurable intervals, and AOF (Append-Only File), which logs every write operation to a file that can be replayed on restart. Both can be used together. The default Redis configuration has persistence disabled to maximize performance, which is correct for pure caching use cases but incorrect when durability matters. Redis is accurately described as an in-memory data store that optionally persists to disk, not as a purely volatile store.

False. Redis Pub/Sub is fire-and-forget with no message persistence or delivery guarantees. If a subscriber is not connected at the moment a message is published, the message is lost. This makes Pub/Sub suitable only for real-time broadcasting scenarios where message loss is acceptable (such as live chat or real-time dashboards). For workloads requiring guaranteed delivery, Redis Streams (introduced in Redis 5.0) provide persistent, consumer group-based message delivery with acknowledgment semantics, making them the correct alternative to Pub/Sub when durability matters.

Hashes are ideal for sessions: the HSET/HGET commands operate on individual fields without touching the rest of the document, enabling efficient partial updates (updating last_seen without re-serializing the entire session). Storing as a String/JSON (option B) is a valid trade-off when the entire session is always read together and field-level access is not needed, but it is inefficient for partial updates. TTL on the Hash key (option D) provides automatic session expiry, which is essential for preventing session accumulation. Lists (option C) are ordered by insertion, not time-based search - they are not appropriate for session management.

Redis excels at session storage (in-memory speed, TTL-based expiry, Hash structure for field access), real-time counters (INCR is atomic and O(1)), and distributed locking (the SET ... NX ... EX pattern implements the Redlock algorithm for mutual exclusion across instances). A financial general ledger (option B) requires ACID transactions across multiple entities, foreign key constraints, and an immutable audit trail - all characteristics of a relational database. Redis's data model and eventual consistency under failure scenarios make it unsuitable as a primary store for financial data requiring strict consistency.

AOF (Append-Only File) is Redis's log-based persistence mechanism. Every write command (SET, LPUSH, ZADD, etc.) is appended to the AOF file. On restart, Redis replays the AOF from the beginning to reconstruct the dataset. AOF files can be rewritten (AOF rewrite / BGREWRITEAOF) to compact the log by replacing obsolete commands. The appendfsync setting controls flush behavior: always (per command), everysec (once per second, default), or no (OS-controlled). Compared to RDB, AOF provides finer recovery granularity at the cost of larger files and slightly slower restart times for very large datasets.

INCR is one of Redis's most important atomic operations. It reads the current value, increments it by 1, and writes the result - all as a single atomic operation with no possibility of a race condition. If the key does not exist, Redis treats it as 0 and sets it to 1. This atomicity makes INCR suitable for distributed counters, rate limiters, and unique ID generation without any external locking. INCRBY increments by a specified amount, INCRBYFLOAT increments by a float, and DECR/DECRBY decrement. All are guaranteed atomic in single-threaded Redis.

Each Redis data structure maps to a specific problem shape. Strings are the simplest key-value storage - ideal for caching serialized responses (JSON/protobuf) with a TTL. Hashes efficiently store structured objects with multiple fields, enabling partial reads and updates without full deserialization - perfect for sessions. Sorted Sets maintain score-ordered members automatically, making them ideal for leaderboards, priority queues, and time-windowed rate limits. Lists provide O(1) head and tail operations - LPUSH adds to the front, BRPOP (blocking pop) removes from the back - the exact FIFO pattern for task queues.

The decision between Sentinel and Cluster starts with data size: if the full dataset fits in a single node's RAM (10GB here), Sentinel provides high availability through automatic failover without the operational complexity of sharding. Cluster is needed when the dataset exceeds single-node capacity or when throughput requires distributing load across multiple write primaries. Multi-key operation consistency is a critical Cluster constraint to evaluate if the application uses MGET, MSET, or Lua scripts across multiple keys. At 10GB fitting comfortably in a single node, Sentinel is the simpler and correct choice.

Redis RAM is significantly more expensive per GB than object storage (S3, GCS, Azure Blob). Storing large binary blobs in Redis wastes expensive in-memory space on data that does not benefit from Redis's microsecond access latency (image delivery latency is dominated by network transfer to the browser, not Redis retrieval). The correct architecture stores images in object storage and uses Redis to cache only the hot metadata (image URLs, dimensions, tags) or to maintain access control tokens. This is a common Redis anti-pattern in teams new to in-memory databases.

Redis Cluster uses exactly 16,384 hash slots (2^14). Each key is assigned to a slot using CRC16(key) mod 16384. These slots are distributed across the cluster's master nodes - for example, a 3-node cluster might give nodes 0-5460, 5461-10922, and 10923-16383. The 16,384 limit was chosen by Redis's creator as the practical upper bound for cluster size (more than 1,000 nodes is not recommended) while keeping the cluster configuration message small enough for efficient gossip propagation. Hash tags ({user_id}) force multiple keys to the same slot to enable multi-key atomic operations.