Cache Classification and Practical Cases in High‑Traffic Systems

Cache is a primary tool for improving system performance in Internet applications, and it is widely used in practice. This article first classifies caches and then shares practical scenarios encountered in real business.

Cache Classification

Common cache types include client cache, browser cache, CDN cache, NGINX cache, application cache, and unified cache such as Redis.

Client Cache is rarely used and typically found in traditional enterprises; it stores rarely changing data in local files accessed via JavaScript.

Browser Cache stores previously requested web resources (HTML, images, JS, CSS) in the browser, reducing bandwidth, server load, and latency.

CDN Cache places data in edge servers to serve users from the nearest node, mainly for static assets.

NGINX Cache creates local copies of content on the NGINX server to reduce traffic between NGINX and backend services.

Application Cache uses components like Ehcache or Guava in Java applications, or thread‑local caches for high‑frequency internal calls.

Unified Cache (e.g., Redis or Memcached) stores data in memory to reduce direct database access.

Among these, the last two (application and unified caches) are most frequently used by developers.

Practical Cases

1. Hotspot Key

During a major promotion, a large number of HTML fragments were served, leading to a hotspot key in Redis with up to 4 million requests per minute. The initial approach of caching solely in Redis caused performance degradation and even instance crashes.

The solution added a local JVM cache with a one‑minute TTL, falling back to Redis and the database when needed. Additionally, NGINX gzip compression reduced payload size from ~73 KB to ~13 KB, and NGINX proxy caching stabilized performance.

2. Category Center Design

The category center is a core data service for e‑commerce, requiring high performance and stability. A three‑tier cache was implemented: client cache, JVM cache in the category service, and a unified Redis cache.

Update flow: update the database, then Redis, then all JVM instances, and finally the version number to force client refresh. Redis locks ensure only one task refreshes data at a time.

Statistics show 95% client cache hit rate, 3.7 million client requests per minute, and server load remaining low (1.5 million calls per minute per instance).

Conclusion

Cache can serve both as a cache and as a pseudo‑database to avoid cache‑penetration.

Data updates involve both active and passive cache handling.

Ensuring data consistency and validity is essential.

Choosing what to cache, how to combine caches, and which data to store must be driven by business scenarios and continuous observation and summarization.