7 Common Cache Pitfalls and How to Avoid Them in Backend Systems

Introduction

Cache is frequently used in daily work, but improper usage can lead to many pitfalls.

This article summarizes seven cache pitfalls encountered in practice and offers valuable references.

1 Cache Penetration

When a user requests an ID that does not exist in the cache, the request falls through to the database each time, causing unnecessary load.

Solutions:

1.1 Parameter Validation

Validate user IDs and reject malformed requests early.

1.2 Bloom Filter

Use a Bloom filter to quickly determine if a key might exist before querying the database.

1.3 Cache Empty Values

Cache empty results for non‑existent IDs to prevent repeated database hits.

2 Cache Breakdown

When a hot key expires, a surge of requests can overwhelm the database.

2.1 Locking

Use a distributed lock to ensure only one request accesses the database for a given product ID.

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

2.2 Automatic Renewal

Refresh keys before they expire using a scheduled job.

2.3 Permanent Keys

For certain hot data, keep the cache entry permanent and pre‑warm it before high‑traffic periods.

3 Cache Avalanche

Simultaneous expiration of many hot keys can cause a massive database load.

3.1 Randomized Expiration

Add a random 1‑60 second offset to each key’s TTL to avoid synchronized expiration.

actualTTL = baseTTL + random(1, 60);

3.2 High Availability

Deploy Redis in Sentinel or cluster mode to survive node failures.

3.3 Service Degradation

Provide fallback data when the cache is unavailable.

4 Data Inconsistency

Four common strategies for maintaining cache‑DB consistency are discussed, highlighting the drawbacks of each.

4.1 Write Cache First

Risk of dirty cache if the subsequent DB write fails.

4.2 Write DB First

Potential inconsistency if cache write fails after DB commit, especially under high concurrency.

4.3 Delete Cache First

May cause stale reads during concurrent operations.

4.4 Write DB Then Delete Cache

Generally safe, but edge cases exist when cache expires simultaneously.

5 Large Key Problem

Storing overly large values in Redis can degrade performance.

5.1 Reduce Field Names

Compress JSON by shortening field names.

@AllArgsConstructor<br/>@Data<br/>public class Category {<br/>  @JsonProperty("i") private Long id;<br/>  @JsonProperty("l") private Integer level;<br/>  @JsonProperty("n") private String name;<br/>  @JsonProperty("p") private Long parentId;<br/>  @JsonProperty("c") private List<Category> children;<br/>}

5.2 Data Compression

Compress JSON to byte arrays before storing in Redis.

6 Hot Key Problem

Uneven distribution of hot keys can overload a single Redis node.

6.1 Split Keys

Distribute hot data across multiple nodes.

6.2 Add Local Cache

Introduce an in‑process cache to reduce Redis load, accepting possible staleness.

7 Cache Hit Rate Issues

Low hit rates hurt performance; solutions include cache pre‑warming, appropriate TTL settings, and increasing cache memory.

7.1 Cache Pre‑warming

Load essential data into cache at service startup.

7.2 Adjust Expiration Times

Set reasonable TTLs to balance freshness and hit rate.

7.3 Increase Cache Memory

Allocate more memory to reduce evictions.