Redis for System Design

How many threads does REDIS have?

Redis operates on a single thread. This means it processes one request at a time; the first request arrives and runs while others wait. While this fails to utilize multi-core systems, it significantly simplifies the order of operations and reasoning about concurrency compared to other databases.

Where does REDIS store its data?

Redis stores data entirely in memory, allowing for lightning-fast, sub-millisecond response times. This design choice implies that while it is incredibly fast, durability is not guaranteed in the same way as a disk-based SQL database, though it changes how you can interact with the DB (e.g., no need to batch requests to avoid overhead).

How does Redis differ from a standard Key-Value store? ie. How does REDIS store its data?

Redis is a "Data Structure Server." It doesn't just store simple strings or blobs; it understands complex data types like Hash Maps, Lists, Sets, and Sorted Sets.

• Benefit: You can perform complex operations (like popping an item from a list or incrementing a hash field) atomically on the server side, reducing network overhead.

Since Redis is in-memory, how does it ensure data isn't lost if the server crashes? ie. How does Redis handle durability? 

Redis writes every command to an Append Only File (AOF) on the disk.

• Recovery: When Redis restarts, it replays this log to reconstruct the state.

• Replication: This log is also used to keep Secondary (replica) nodes in sync with the Master node

What are some concepts associated with scaling a Redis server?

• Avoiding Hot keys 

• Vertical Scaling

• Horizontal Scaling

• Sharding → (automatic is redis with 16384 hash slots) splitting your keys across multiple Redis instances so each one handles only part of the data + traffic.

• Replication (read relicas)

• connection pooling and pipelining (send multiple commands in one go) to reduce network overhead.

• Set maxmemory and a eviction policy so Redis knows what to evict when memory is full (allkeys-lru, allkeys-lfu, etc.).

Append Only File (AOF)

a log file on disk where Redis writes every command that changes data, one after another, in order.Later, if Redis restarts, it can replay that log (run those commands again) to rebuild the in-memory data.

What happens on Redis restart?

When Redis restarts with AOF enabled:

1. It opens the AOF file.

2. Reads it from the top, command by command.

3. Re-runs each command in order, exactly like a client sent them.

4. After it finishes, memory now matches what it looked like before the crash/restart.

What are the AOF fsync policies? (how often it’s flushed to disk)

• always (fsync every write)

  • Every command:

    • execute → append to file → flush to disk → then OK is returned to client.

  • Pros: Most durable — you basically don’t lose commands.

  • Cons: Slowest; higher latency.

• everysec (default)

  • Redis appends commands to the OS buffer right away.

  • A background thread flushes them to disk roughly every 1 second.

  • Pros: Good performance, small risk (you might lose up to ~1 second of data if machine dies).

  • Cons: Not “perfect” durability.

• no

  • Redis writes to the OS buffer but never forces a flush.

  • The OS decides when to flush (maybe every ~30 seconds).

  • Pros: Fastest.

  • Cons: You can lose several seconds of data on crash

What is the problem with AOF (Append Only File)

The problem is that it grows forever. 

How do you solve redis’s Append only files “growing forever problem“? 

Compaction. Using a process called AOF rewrite. To put it in simple terms, It occasionally “summarizes” the log via rewrite to keep it small and fast 

Append only file rewrite. 

AOF rewrite is redis saying “Let me look at what’s in memory right now and write the shortest script of commands that would recreate that state from scratch.” AOF rewrite is a background process where Redis takes the current in-memory dataset and generates a new, compact AOF containing only the minimum commands needed to rebuild that state. During the rewrite, Redis keeps appending new writes to the old file and a buffer, then merges those into the new file and atomically switches over when done.”

Hash Slots

numbered buckets (0–16383) that Redis uses to decide which node stores which key in a cluster.

• Redis Cluster has many nodes (machines), and your keys need to be spread across them.

• Instead of sending keys randomly, Redis divides the world into 16,384 buckets called hash slots. Redis+1

• Every key is run through a hash function and assigned to one specific hash slot.

• Each Redis node is responsible for some range of hash slots (like “node A handles slots 0–5000, node B handles 5001–10000”, etc.). Redis+1

• When you add or remove nodes, Redis just moves hash slots between nodes instead of moving keys one by one in a random way.

• The slot is calculated as: CRC16(key) % 16384.

How does Redis Cluster determine which node stores a specific key?

It uses Hash Slots.

• There are 16,384 total slots.

• The slot is calculated as: CRC16(key) % 16384.

• Each node in the cluster is assigned a range of these slots.

In a distributed Redis cluster, how does a client find the right node?

Redis clients are "cluster-aware." They cache the map of which slots belong to which nodes. The client locally hashes the key, finds the correct node, and sends the request directly to it (unlike a load balancer which might hop).

Smart Clients (Client-Side Routing)

cluster-aware Redis clients that do their own routing. Smart Client is a Redis library that keeps a little routing table in memory so it always talks straight to the right node instead of asking some middleman. 

• In Redis Cluster, data is split across many nodes using hash slots. Redis+1

• A smart client (Jedis, go-redis, StackExchange.Redis, etc.) downloads the hash-slot → node map from the cluster and caches it locally. Redis+1

• When your code does GET user:123, the client:

  • Calculates which hash slot that key belongs to.

  • Looks up which node owns that slot.

  • Sends the command directly to that node (no proxy in the middle). Amazon Web Services, Inc.+1

• If the cluster replies with MOVED / ASK (because slots moved), the client updates its map and retries automatically.

What happens if one key (e.g., a popular celebrity's tweet) receives massive traffic, overwhelming a single node?

Replicate the key. Append a random number to the key (e.g., tweet:123_1, tweet:123_2) and copy the data to these new keys. This spreads the read/write load across multiple slots and therefore multiple nodes.

INCR Command

Increases a number stored at a key by 1, in an atomic way.

INCR counter

if counter is 5, Redis changes it to 6.

INCR with Expire Command

INCR requests:127.0.0.1
EXPIRE requests:127.0.0.1 60

What each piece does

• INCR key

  • Treats the value as a number and adds 1.

  • If the key doesn’t exist, it starts at 1.

• EXPIRE key seconds

  • Says: “This key should automatically disappear after N seconds.

When INCR and EXPIRE are used in conjunction, You’re creating a counter that automatically resets after some time.

How do you implement a basic rate limiter in Redis?

Use the atomic INCR command combined with EXPIRE.

• Logic: Create a key for the user/IP. Increment it on every request. If the value > Limit, block. Set a TTL (Time To Live) on the key so the counter resets automatically after the window (e.g., 1 minute).

• Every request:

  • INCR a key like rate:ip:1.2.3.4

  • Make sure it has EXPIRE set to 60 seconds

• If the value > 100 → block that IP.

What happens when Redis runs out of memory while being used as a cache?

It uses an eviction policy, typically LRU (Least Recently Used). Redis identifies keys that haven't been accessed in a while and deletes them to make space for new writes.

What are common redis eviction policies?

Common policies:

• noeviction – don’t remove anything; new writes fail with an error.

• allkeys-lru – remove least recently used keys.

• allkeys-lfu – remove least frequently used keys.

• allkeys-random – remove random keys.

• volatile-lru / volatile-lfu – like above, but only for keys that have a TTL (EXPIRE).

Which data structure is best for real-time leaderboards and why?

Sorted Sets (ZSET).

• Mechanism: Each item has a "score." Redis sorts items by this score.

• Efficiency: Updating a score is logarithmic o(logN). You can retrieve the "Top 10" instantly without sorting the whole list every time.

Sorted Set (ZSET)

A set of unique strings, where each member has a numeric score, and Redis keeps them ordered by that score. It is like a a ranking/leaderboard structure: you store players + scores, and Redis can quickly tell you “who’s in the top N” or “who’s between these scores.”

Key points in simple terms:

• Each item = (member, score)

  • Example:

    • "alice" with score 100

    • "bob" with score 80

• Members are unique (no duplicates), but scores can repeat.

• Redis always keeps them sorted by score, so you can:

  • Get “top 10” easily (like a leaderboard).

  • Get all members with score between X and Y.

  • Get rank of a member

Common commands (just to recognize the names):

• ZADD – add/update a member with a score.

• ZRANGE / ZREVRANGE – get items by rank (low→high or high→low).

• ZRANGEBYSCORE – get items by score range.

ZADD tiger_posts 500 "SomeId1" # Add the Tiger woods post
ZADD tiger_posts 1 "SomeId2" # Add some tweet about zoo tigers
ZREMRANGEBYRANK tiger_posts 0 -6 # Remove all but the top 5 post

How does Redis store location data for "nearby" searches?

It uses Geohashing.

• Lat/Lon coordinates are converted into a hash (a number).

• These are stored in a Sorted Set, where the score is the geohash.

• Because geohashes of nearby points share similar prefixes, Redis can efficiently query for items within a radius (bounding box).