How to use Redis in system design interviews?

Complete guide to using Redis in System Design Interviews: Key use cases and examples

Cracking system design interviews often requires a deep understanding of specific technologies, especially for senior roles. Even for junior positions, building a solid foundation early on helps. Redis is one of those key components interviewers often expect you to know well, and here’s why:

1. Versatility: Redis isn't just a cache; it handles diverse use cases, such as rate limiting, session management, leaderboards, etc.

2. Simplicity and Speed: Redis excels at executing simple operations quickly, making it perfect for high-performance systems.

Redis can do much more than just caching and can be a major technology in the Design Deep Dive interview phase. In this article, we’ll dive into the key systems you can design using Redis.

If you are a recent subscriber, here’s what you might have missed:

1. How to crack any system design interview?

2. A crash course on Caching—Part 1, Part 2 & Part 3

3. What are Load Balancers?

4. A crash course on Rate Limiters - Part 1 & Part 2

---

Redis Basics: Why and how Redis is essential for system design

Redis is an open-source, in-memory data store renowned for its speed and efficiency. It supports various data structures like strings, hashes, lists, and sets, making it ideal for core use cases such as caching, rate limiting, pub/sub messaging, and even designing social media feeds.

Why Is Redis Fast?

• In-Memory Storage: Redis stores data in RAM, making it significantly faster than disk-based storage.

• Single-threaded Architecture: Redis processes all requests on a single thread, avoiding the overhead of context switching and locks.

• Non-blocking I/O: An event loop and asynchronous request handling ensure low latency and high throughput.

• Optimized Data Structures: Redis uses efficient data structures for fast read/write operations.

Understanding Redis data structures

Strings are commonly used for:

1. Storing session data for users in web applications

2. Caching frequently accessed API responses.

Lists are commonly used for:

1. Implementing a message queue for asynchronous tasks.

2. Storing a timeline in social media applications.

Sets are commonly used for:

1. Tracking unique visitors to a website.

2. Maintaining a list of unique hashtags used in posts.

Sorted Sets: This data structure combines a hash table and a sorted tree. Each entry has a string "member" (the key) and a double "score" (the sorted value). This allows you to access entries directly by member or score, and retrieve members in order based on their score.

Use cases of Sorted Sets:

1. Creating a leaderboard for an online game.

2. Ranking search results based on the number of likes for a keyword.

Hashmaps: Useful for storing structured data like objects. Commonly used for:

1. Storing user profiles with fields like name, email, and age.

2. Caching database query results in a structured format.

Essential Redis commands for system design

SET foo 1  
GET foo     # Returns 1
INCR foo    # Returns 2
ZADD leaderboard 100 user1    # Adds a user to a sorted set (leaderboard) with score 100
ZRANGE leaderboard 0 0 WITHSCORES    # Returns the top user and score in the leaderboard
SADD users user1     # Adds user1 to a set of users
SMEMBERS users     # Retrieves all members of the set
HSET user:1 name "John Doe" age 30    # Stores structured data in a hash
HGETALL user:1    # Retrieves all fields and values from the hash
XADD mystream * name Sara surname OConnor    # Adds an item to a stream

---

Top Redis use cases in System Design interviews

In this section, we will explore each system that can be built on top of redis in detail along with the data structures that make this possible.

Redis as a cache

The most common use case of Redis is as a “cache”. It is deployed in a multi-node setup where Consistent Hashing is used to distribute keys across nodes to ensure high availability. Cache Aside is the most commonly used caching strategy where Time To Live (TTL) is often employed on each key for expiry. Redis guarantees you'll never read the value of a key after the TTL has expired and the TTL is used to decide which items to evict from the server - keeping the cache size manageable even in the case where you're trying to cache more items than memory allows.

Figure 1: Redis as a cache (Cache Aside pattern)

Redis as a distributed lock: Ensuring data consistency in System Design

Another use case of Redis is as a distributed lock. Occasionally we have data in our system and we need to maintain consistency during updates, or we need to make sure multiple people aren't acting at the same time.

Tip💡: Most databases (including Redis) will offer some consistency guarantees. If your core database can provide consistency, don't rely on a distributed lock which may introduce extra complexity and issues. Your interviewer will likely ask you to think through the edge cases in order to make sure you really understand the concept.

Figure 2: Redis as a distributed lock

Figure 2 shows how a simple distributed lock works. When we want to try to acquire the lock, we run INCR with a TTL. If the response is 1 (ie: we own the lock), we proceed. If the response is > 1 (ie: someone else has the lock), we wait and retry again later. When we're done with the lock, we can DEL the key so that other proceesses can make use of it.

Redis as Leaderboard in Gaming applications

Redis' sorted sets maintain ordered data which can be queried in log time which make them appropriate for leaderboard applications. The high write throughput and low read latency make this especially useful for scaled applications where something like a SQL DB will start to struggle.

Figure 3 shows how this happens:

• Game Service adds players to the Redis sorted set (leaderboard) using ZADD, associating each player with a score and unique ID.

• When a player's score changes, the application updates the sorted set with the new score using ZADD, which automatically updates the existing score.

• The application fetches the top 10 players from the leaderboard using ZRANGE leaderboard 0 9 WITHSCORES, ordered by score.

• The rank of a specific player is found using ZREVRANK leaderboard player_123.

Figure 3: Redis as Leaderboard

Redis as a Rate Limiter: Best Practices for High Traffic Systems

As a data structure server, implementing a wide variety of rate-limiting algorithms is possible. A common algorithm is a fixed-window rate limiter where we guarantee that the number of requests does not exceed N over some fixed window of time W. A crash course on Rate Limiting talks about different rate-limiting algorithms and their pros & cons.

Figure 4 shows a simple implementation of a Rate Limiter in Redis. When a request comes in, we increment (INCR) the key for our rate limiter and check the response. If the response is greater than N, we wait. If it's less than N, we can proceed. We call EXPIRE on our key so that after time period W, the value is reset.

Figure 4: Redis as Rate Limiter

Locating nearby drivers with Redis Geohashes in ride-hailing apps

Redis can help locate nearby drivers in ride-hailing services like Uber. Sorted Set is the data structure that facilitates this and the algorithm involved is called Geohashing

• Geohash: A 52-bit integer created by interleaving the bits of a driver's latitude and longitude coordinates.

• Sorted Sets: It stores the driver ID with the corresponding geohash as the score, allowing the set to be sorted based on location (see the sorted set table in Figure 5).

Figure 5: Redis for finding Nearby Drivers

Figure 5 shows a step-by-step breakdown of how this happens:

1. Driver Location Service:

   • Updates Redis with driver locations using GEOADD drivers:current_location 13.3 38.1 "driver_123" (sorted set name, latitude, longitude, driver ID).

   • A geohash is calculated from lat/long pair and is stored as a score with the driver_id in a sorted set (drivers:current_location)

2. Ride Request Service:

   • Queries Redis for nearby rides using GEOSEARCH drivers:current_location FROMLONLAT 15.0 37.0 BYRADIUS 2km (sorted set name, user’s lat/long, radius).

   • Computes a geohash/score from the user’s coordinates to find the closest drivers in the drivers:current_location sorted set.

   • Retrieves driver IDs and additional details (availability, ETA) from Redis or another data store.

Tips 💡:

1. There are additional complexities to consider in “Finding nearby drivers in Uber”, such as the status of drivers who may be available or currently completing another ride.

2. Depending on search traffic, it may be necessary to maintain different sorted sets for various locations.

3. Redis is best utilized for scenarios where latitude and longitude updates occur frequently (eg: finding nearby drivers in Uber). For use cases with infrequent location changes, like storing the locations of all outlets for a store, static data storage is more appropriate.

Redis for async communication: Message Queues

Redis provides a List data structure that can be utilized as a queue to facilitate asynchronous communication between services. Below is a step-by-step overview of how to implement Redis for an image processing use case:

1. The user uploads an image and the image service pushes a job to the Redis list image_queue using LPUSH.

2. The background worker retrieves the job from the queue using BRPOP, waiting if the queue is empty.

3. The worker processes the image (in this case, resizing it).

4. Once the image processing is complete, the worker pushes a completion notification into another Redis list, processed_images.

5. The notification service reads this message to inform the user about the completion.

Figure 6: Redis as a message queue

Downsides of using Redis as a message queue

While Redis can handle this use case, it's not ideally suited for large-scale systems where solutions like Kafka are more appropriate due to the following limitations of Redis:

1. Lack of Message Durability: As an in-memory store, Redis can lose messages if it crashes or restarts. Although it supports persistence through AOF (Append Only Files) and RDB (Redis Database), there are chances of messages getting lost between snapshots.

2. No Message Re-delivery Guarantee: Unlike Kafka, Redis lacks a message commit mechanism, meaning there's no assurance that lost messages will be retried.

3. Not Designed for Scale: Being single-threaded, Redis can become a bottleneck in high-throughput scenarios, whereas distributed message brokers like Kafka or RabbitMQ are built for scalability.

4. No Message Ordering Guarantees: Redis does not guarantee the order of messages when multiple consumers are involved.

Storing and analyzing time series data in Redis

Time series data is a sequence of data points collected or recorded at successive time intervals, typically in chronological order. Each data point is associated with a timestamp, which represents when the data was captured. Common examples of time-series data:

1. Stock Prices: Daily closing prices of a stock over time

2. Weather Data: Temperature readings recorded every hour or day

3. Server Metrics: CPU utilization of a server over time

4. IoT Sensor Data: Sensor readings from devices over time

5. Financial Transactions: Sequence of financial transactions like payments made over time, categorized by timestamp.

Redis provides a NoSQL data structure called RedisTimeSeries which allows storing and querying time series data.

Figure 7 shows the steps involved:

1. The client sends data to the Analytics Service with a timestamp and the number of visits (can also be aggregated by the client and sent at once).

2. The Analytics Service adds this information to Redis using the TS.ADD command, which stores the number of visits with the given timestamp in Redis time series DB

3. TS.RANGE command can be used to retrieve time series data between two timestamps/in the last hour.

4. TS.MRANGE command can be used with an aggregation option (AGGREGATION count 60) to answer queries such as “how many visits occurred per minute”.

Fgure 7: Redis for Time Series data

Managing user sessions with Redis

Another popular use case for Redis is managing user sessions. Its built-in support for time-to-live (TTL) makes it easy to automatically expire sessions after a designated interval.

Figure 8 shows the steps involved:

1. When a user logs in, the Login Service stores the session data for each user (456_session_token: {user_id: 456, logged_in: true}) in Redis using the HSET command.

2. A TTL (eg: 1 hr) is set for every token EXPIRE 456_session_token 3600.

3. During each API request, the login service retrieves the session data by using the HGETALL command on the session token (456_session_token).

4. Session expires after 1hr and the user is prompted to login again.

Figure 8: Redis for storing User Sessions

Redis for top posts in Social Media: Real-Time ranking and engagement optimization

Designing social media feeds or displaying the top posts related to a specific topic is another prevalent use case for Redis. By utilizing sorted sets (ZSET), Redis effectively stores posts as members and uses the number of likes as scores to rank them. As posts receive likes, their scores are updated in real time, maintaining accurate rankings.

Figure 9 shows the steps involved:

1. Whenever a new post is created, relevant keywords are extracted and stored in a Redis sorted set. For instance, a post like “Google launched Gemini…” would use the command ZADD keyword:google 100 post_id_12345 to store its likes.

2. The score of a post can be based on likes, impressions, or other metrics.

3. When a user searches for a keyword (e.g., "google"), the top posts are retrieved using ZREVRANGE keyword:google 0 9 WITHSCORES, which returns the top 10 posts sorted by likes.

4. When a post receives a like, its score is updated to reshuffle rankings with ZINCRBY keyword:google 1 post_id_12345, increasing the likes for that post to 101

5. To manage space, less popular posts are periodically removed. For example, ZREMRANGEBYRANK keyword:google 100 -1 removes all posts ranked below the 100th position, and ZREMRANGEBYSCORE keyword:tiger -inf 9 deletes posts with scores below 10.

Figure 9: Redis for Top posts on social media

---

Other use cases of Redis:

In addition to the use cases already covered, Redis can also be utilized to develop the following systems:

1. Real-time messaging using Pub-Sub (Figure 10)

2. Approximate the cardinality of a large set using HyperLogLog

3. Full-text search using the RedisSearch module

4. Storing nested JSON without re-serialization costs using RedisJSON

Figure 10: Redis as Pub/Sub

---

Conclusion

Redis is a powerful and versatile tool for system design interviews. Its straightforward data structures make it easy to reason about scaling implications, enabling you to engage in in-depth discussions with your interviewer without requiring extensive knowledge of Redis internals.

Apart from Redis, understanding other key technologies such as Kafka, Elasticsearch, Cassandra will give you an edge during deep dives in a system design interview. Will write separate posts on them soon 😉.

---

Thanks for reading!

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone who would find this helpful? Make sure to 🔁 share this post.