Mastering Cache Strategies: Types, Hit Rates, Eviction & Design Patterns

Cache is used to reduce database and server load; when programming consider client cache, server cache, and network (CDN) cache.

Client cache

Server cache

Network cache (CDN)

Client cache reduces server storage and frequent data requests. Example: early QQ stored emojis in the cloud only for members; now most emojis are stored locally.

Client cache types include:

Local file cache (images, .txt, .doc, etc.)

Browser cache (HTTP, cookies)

Registry

Embedded databases (SQLite)

Local memory

Server cache aims to reduce database and external service pressure; it's the most common technique.

Benefits: faster response than DB, avoid external API calls whose latency is uncontrollable.

Server cache categories:

Container cache (Tomcat, Nginx, JBoss, Servlet)

Middleware cache (MongoDB, Elasticsearch, Redis, RocketMQ, Kafka, ZooKeeper)

JDK cache (disk, heap, off‑heap)

Page static cache (FreeMarker, Thymeleaf)

File storage (FastDFS)

01 Cache Hit Rate

Cache hit rate is the ratio of cache queries to total queries. In multi‑level caching, monitor each level's hit rate to adjust code; low hit rate may indicate cache penetration.

02 Cache Eviction Methods

Time‑based : evict when TTL expires or after last access exceeds a threshold.

Space‑based : evict when cache size exceeds a limit.

Capacity‑based : evict when stored entry count exceeds a limit.

Reference‑based : soft/weak references trigger eviction under JVM memory pressure.

03 Cache Eviction Strategies

FIFO : first‑in first‑out, simple queue‑based eviction.

LRU : least recently used, evicts the least recently accessed entry.

LFU : least frequently used, evicts the entry with lowest recent access frequency.

04 Cache Design Patterns

(1) Cache‑Aside : read from cache, fall back to DB on miss; on DB update, delete cache entry. Simple and common for read‑heavy scenarios.

(2) Read/Write‑Through : reads query cache first; on miss, cache loads from DB and never expires. Writes update cache and synchronously persist to DB. Suitable when durability requirements are low.

(3) Write‑Behind (Write‑Back) : all CRUD operations go through cache; cache periodically flushes to DB. Offers highest performance but complex; risk of data loss on crash.

05 Cache Testing Checklist

Check for cache penetration, breakdown, avalanche.

Verify max size and TTL settings; monitor for memory overflow.

Measure read‑saving ratios at each layer (in‑process, Redis, disk, MySQL).

Ensure app functions offline or on weak networks.

Confirm cache refreshes correctly after network recovery.

Validate data consistency across caches and DB (no dirty reads, repeatable reads).

Provide manual cache invalidation or refresh mechanisms for emergencies.

Confirm eviction policies and methods operate as expected.