7 Common Cache Pitfalls and Practical Solutions

Introduction

Cache is widely used to reduce database load and improve system performance, but improper usage introduces many pitfalls. This article summarizes seven common cache issues encountered in practice and provides concrete solutions.

1. Cache Penetration

When a request queries a key that does not exist in both cache and database, every request hits the database, causing unnecessary load. Two typical cases are:

User requests an ID that is absent in cache.

Malicious users forge non‑existent IDs.

Because the cache never stores a value for these keys, each request follows the path: cache miss → database miss → failure, effectively bypassing the cache.

1.1 Parameter Validation

Validate request parameters early. For example, if valid IDs start with 15, reject any ID beginning with 16 before hitting the cache.

1.2 Bloom Filter

For a relatively small dataset, preload all existing keys into an in‑memory map or a Bloom filter. The Bloom filter uses a bit array and multiple hash functions; if all corresponding bits are 1, the key is considered existing, otherwise the request is rejected without touching the database. This dramatically reduces unnecessary DB queries.

1.3 Cache Null Values

Instead of using a Bloom filter, cache a special “null” placeholder when a key is absent in both cache and DB. Subsequent requests retrieve the null value directly from cache, avoiding repeated DB hits.

2. Cache Breakdown (Cache Stampede)

When a hot key expires, a surge of concurrent requests may all miss the cache and flood the database, potentially crashing it.

2.1 Locking

Use a distributed lock to ensure that only one request fetches the data from the DB and repopulates the cache. Example pseudocode:

try {
  String result = jedis.set(productId, requestId, "NX", "PX", expireTime);
  if ("OK".equals(result)) {
    return queryProductFromDbById(productId);
  }
} finally {
  unlock(productId, requestId);
}
return null;

2.2 Auto‑Renewal

Schedule a job to refresh the key shortly before its TTL expires, preventing the key from becoming stale.

2.3 Permanent Keys for Hot Items

For extremely hot items (e.g., flash‑sale products), keep the cache entry permanent and pre‑warm it before the activity starts.

3. Cache Avalanche

An avalanche occurs when many hot keys expire simultaneously or when the cache server crashes, causing massive DB traffic.

3.1 Randomized Expiration

Add a random offset (1‑60 seconds) to each key’s TTL to stagger expirations.

actualTTL = baseTTL + random(1, 60);

3.2 High‑Availability Architecture

Deploy Redis in Sentinel or cluster mode so that a failed master is automatically promoted, ensuring continuous service.

3.3 Service Degradation

When the cache is down, fall back to default data from a configuration center after a threshold of consecutive failures.

4. Data Inconsistency Between DB and Cache

Four typical write‑through strategies are discussed, each with pros and cons.

4.1 Write Cache → Write DB

If the DB write fails after the cache is updated, the cache becomes dirty, leading to incorrect reads.

4.2 Write DB → Write Cache

In low‑concurrency scenarios this works, but in high‑concurrency environments the cache may be written after the DB, causing stale data. Additionally, if the cache write fails, the DB and cache diverge.

4.3 Delete Cache → Write DB

Delete the cache before updating the DB to avoid stale reads, but race conditions can still cause inconsistency if a read occurs between delete and DB write.

4.4 Write DB → Delete Cache

Write the DB first, then delete the cache. If a read happens before the delete, it may fetch stale data; however, this scenario is rare.

5. Big‑Key Problem

When a single key’s value becomes too large (e.g., a category tree with tens of thousands of nodes), Redis operations slow down.

5.1 Shrink Field Names

Store only necessary fields and rename them to short identifiers during JSON serialization, reducing per‑record size.

@JsonProperty("i") private Long id;
@JsonProperty("l") private Integer level;
@JsonProperty("n") private String name;
@JsonProperty("p") private Long parentId;
@JsonProperty("c") private List<Category> children;

5.2 Data Compression

Compress JSON strings to byte arrays using GZip before storing them in Redis, then decompress on read. This can shrink the stored size by an order of magnitude.

6. Hot‑Key Problem

Popular keys concentrate traffic on a single Redis node, risking overload.

6.1 Split Keys

Identify hot items in advance and distribute them across different Redis nodes to balance load.

6.2 Add Local Cache

Introduce an in‑process cache layer for hot data to reduce remote Redis accesses, at the cost of potential staleness.

7. Low Cache Hit Rate

A low hit rate forces frequent DB queries, degrading performance.

7.1 Cache Warm‑Up

Pre‑populate cache with essential data during service startup using background jobs.

7.2 Adjust Expiration Times

Set reasonable TTLs (e.g., increase from 1 s to 30 s or 1 min) to keep data alive longer.

7.3 Increase Cache Memory

Provision more RAM for Redis to accommodate more keys and avoid eviction.