Redis in System Design Interviews: The Hot Key Problem Most Engineers Miss

Recently, I was helping an engineer prepare for a system design interview. We were working through a classic question together -“the like system for a viral post.”

They gave a great first answer: “We’ll store likes in Redis and use INCR.” And honestly, that’s a solid instinct because it’s fast, simple, and gets the job done at most scales.

But as we dug deeper, some interesting questions came up:

• What happens when 1 million people like the same post at the same time?
• Why does a Redis cluster get a hot node and how to tackle that?

Suddenly, the simple Redis counter wasn’t simple anymore. This is one of the most common pitfalls in system design interviews. Many engineers know Redis commands, but interviews test whether you understand bottlenecks, hot keys and distributed tradeoffs.

In this article I’ll walk through the most common Redis scenarios in system design interviews and how staff-level engineers approach them.

The Classic System Design Question: Celebrity Likes

Imagine you’re building a social media platform. A celebrity posts something. Within seconds, 1 million users press “Like”. Your system stores likes in Redis:

post:123:likes
Each request increments the counter:
INCR post:123:likes

Redis is fast, so this should work. Right? Not Exactly.

The mental model

Think of Redis Cluster like this:

Redis Cluster
 ├─ Node A
 ├─ Node B
 └─ Node C

Each key is hashed to exactly one node. So if all writes hit post:123:likesthen every write goes to the same node, creating a hotspot. Even if the cluster has 100 nodes, one key still maps to one node (hotspot).

The Hot Key Problem

Even in a Redis cluster, a single key lives on one shard. If millions of requests hit the same key (post:123:likes), all traffic goes to the Redis node responsible for that key. That node becomes overloaded while the rest of the cluster remains mostly idle. This is called a hot key. It shows up everywhere in real systems:

• Celebrity posts
• Trending hashtags
• Rate limiters
• Global counters
• Popular products
• Leaderboard entries

A strong system design answer should recognize this immediately. So what are the solutions?

Sharded Counters

Instead of one key (post:123:likes), we create multiple physical keys that represent the same logical counter: post:123:likes:0 post:123:likes:1 post:123:likes:2 post:123:likes:3 post:123:likes:4

Redis Cluster distributes keys across nodes using hashing, so different keys are typically stored on different nodes. A single key always lives on one node, which means a heavily accessed key can overload that node. By creating multiple keys such as post:123:likes:0, post:123:likes:1, and post:123:likes:2, the system allows Redis to hash those keys independently. As a result, they are typically distributed across multiple nodes, spreading the write load across the cluster.

num_shards = 5
post_id = 123

shard = random.randint(0, num_shards - 1)

key = f"post:{post_id}:likes:{shard}"
redis.incr(key)

The application chooses which shard counter to update. A common approach is to pick a shard randomly so that writes distribute evenly across keys.

Write path: the API server picks a random shard (0–4) on every like event and fires a single atomic INCR against that shard key. This avoids write contention on a single key while staying lock-free. Node A holds shards 0 and 3, Node B holds shard 1, and Node C holds shards 2 and 4. The active shard (3) targeted by the write is highlighted so you can trace the path end-to-end.

This solves the write bottleneck, but introduces a new tradeoff called the read amplification problem.

Read cost: 1 client request → 5 Redis reads → 1 aggregation step → 1 response. This pattern is often called fan-out reads, where a single request must fetch data from multiple keys before returning a response. Trade-off: writes are fast and contention-free; reads pay the fan-out cost

The logical like count now exists across multiple keys. To get the total likes, the system must aggregate all shards. For example: 1 request → 5 Redis reads (assuming 5 shards)

If thousands of users request the count simultaneously, read traffic can multiply quickly. In practice, systems often mitigate this with:

• Cached Aggregated Count (Maintained via Background Aggregation): In some systems, a separate aggregated key is maintained to avoid summing shards on every read.

post:123:likes:0
post:123:likes:1
post:123:likes:2
post:123:likes:3
post:123:likes:4

post:123:likes:total

Reads now hit the cached key (post:123:likes:total) instead of summing all shards every time. However, in a true hot-key scenario, updating post:123:likes:total on every write would simply create another hotspot. Instead, systems usually maintain this key asynchronously. A background worker periodically sums the shard counters and stores the merged result in post:123:likes:total.

total = 0
for i in range(5):
    key = f"post:123:likes:{i}"
    total += int(redis.get(key) or 0)

redis.set("post:123:likes:total", total)

This approach is useful in products where exact-to-the-millisecond accuracy is not required for counters.

When Exact Accuracy Isn’t Required

In many real-world systems, the business requirement does not require an exact like count at every moment. For example, a post may only need to display an approximate count such as “10.2K likes,” where small variations are acceptable. In these cases, systems can trade a small amount of accuracy for better performance.

One approach is to sample only a subset of shards when reading the counter instead of aggregating every shard. For example, if a counter is split across 20 shards, the system may read only 5 of them and estimate the total count based on the sample. This reduces read amplification while still producing a close approximation.

Another approach uses probabilistic data structures such as Count-Min Sketch. These structures allow systems to estimate frequencies using far less memory and fewer writes, at the cost of small bounded errors. They are commonly used in large-scale systems to track popular items, trending topics, or approximate counters.

The key takeaway is that counter accuracy is often a product decision, not just a technical one. When exact precision is not required, approximate counting techniques can dramatically reduce system load.

When Traffic Gets Extreme

Even sharded counters can struggle under massive spikes. If millions of users interact with the same post within seconds, the API layer and Redis cluster can still experience sudden bursts of traffic.

In many large-scale systems, Kafka is already part of the write path not specifically introduced to solve the hot key problem, but because decoupling user requests from storage is a common architectural pattern at scale. Instead of the API writing directly to Redis, it publishes events to Kafka. Consumer services then process those events and update Redis counters. This consumer layer is a natural place to apply the same sharded counter strategy.

Kafka also helps absorb sudden traffic spikes. By publishing like events to Kafka first, the system can buffer incoming requests and process them at a controlled rate. In this model, Kafka acts as a shock absorber for write volume, smoothing bursts of activity before updates reach Redis. The architecture becomes:

Users → API → Kafka → Aggregator → Redis

Instead of writing each like directly to Redis, the API publishes an event:

{ postId:123, userId:456, action:"like" }

Kafka stores these events and allows consumers to process them at a controlled rate. Aggregator workers read events from Kafka in batches and update Redis using aggregated increments. These updates are still applied to the sharded counters:

INCRBY post:123:likes:0 120
INCRBY post:123:likes:1 95
INCRBY post:123:likes:2 110

Kafka acts as a shock absorber for traffic spikes. Instead of millions of writes hitting Redis simultaneously, events are buffered and processed in batches, smoothing the load on the system.

This changes the system from synchronous writes to an event-driven pipeline, allowing the system to absorb sudden spikes without overwhelming Redis.

The Subtle Kafka Bottleneck

However, another bottleneck can appear. Suppose Kafka partitions events by postId. All likes for the same post will be sent to the same Kafka partition. For a celebrity post, that means one partition and one consumer receive most of the traffic, while the rest of the system remains underutilized. In other words, the hotspot has simply moved from Redis to Kafka.

One way to address this is to salt the partition key spreading events for the same post across multiple partitions..

For example, instead of using post:123 the producer may use keys such as:

post:123:0
post:123:1
post:123:2
post:123:3

Now events for the same post can be distributed across multiple partitions and processed by multiple consumers in parallel. Downstream consumers then aggregate the counts before updating Redis.

The tradeoff is that events for the same post no longer have strict global ordering, since they are processed across multiple partitions. For counters such as likes, this loss of ordering is usually acceptable.

Whenever Redis appears in a system design interview, ask yourself:

1. Could this key become hot?
2. Are reads or writes the bottleneck?
3. Do we need buffering for traffic spikes?
4. Is eventual consistency acceptable?
5. What happens when a node fails?

The engineer started with a one-line answer. By the end of our session, he could trace a like event from a user’s tap all the way through a Kafka buffer, an aggregator worker, and into a sharded Redis counter and explain exactly where each bottleneck lives and why.

That progression is what interviewers are looking for. Not the perfect answer upfront, but the ability to start simple, spot the cracks, and reason your way to something that holds up at scale. Knowing Redis commands is easy. Understanding where systems break at scale is what system design interviews actually test.