Principles of Caching: Strategies and PatternsPrinciples of Caching: Strategies and Patterns

------

1. Motivation for Cachinging1. Motivation for Cachinging

1.1 The Evolution from "Query Every Time" to "Remember Frequently Used Data"1.1 The Evolution from "Query Every Time" to "Remember Frequently Used Data"

In the early days of computing, programmers would query the hard drive or database every time they needed data. It's like flipping through a textbook to look up a formula for every single math problem — accurate, but terribly inefficient. As systems scaled, this "query every time" approach began to expose serious problems: database CPU spiking to 95%, response times ballooning from 100 milliseconds to 8 seconds, and eventually, complete system collapse.In the early days of computing, programmers would query the hard drive or database every time they needed data. It's like flipping through a textbook to look up a formula for every single math problem — accurate, but terribly inefficient. As systems scaled, this "query every time" approach began to expose serious problems: database CPU spiking to 95%, response times ballooning from 100 milliseconds to 8 seconds, and eventually, complete system collapse.

This is like a student who runs from the dorm to the library to look up references for every class, 50 trips a day, eventually collapsing from exhaustion halfway there. The solution is simple: keep a notebook of commonly used formulas in your backpack, and check the backpack first instead of running to the library every time. Caching is the computer system's "formula notebook" — it stores frequently used data in a fast-access location so the system doesn't have to go to the "library" (the database) every time.This is like a student who runs from the dorm to the library to look up references for every class, 50 trips a day, eventually collapsing from exhaustion halfway there. The solution is simple: keep a notebook of commonly used formulas in your backpack, and check the backpack first instead of running to the library every time. Caching is the computer system's "formula notebook" — it stores frequently used data in a fast-access location so the system doesn't have to go to the "library" (the database) every time.

This is the core problem caching solves: by storing copies of frequently used data, it reduces access to slow storage (the database), making the system faster and more stable.This is the core problem caching solves: by storing copies of frequently used data, it reduces access to slow storage (the database), making the system faster and more stable.

1.2 Case: Caching Is a Lifesaver1.2 Case: Caching Is a Lifesaver

You might be thinking: "My system is fine right now, why design for caching in advance?" Let me tell you a real story so you understand why caching is not "optional" but "mandatory."You might be thinking: "My system is fine right now, why design for caching in advance?" Let me tell you a real story so you understand why caching is not "optional" but "mandatory."

------

2. Core Concepts: Overview of Caching2. Core Concepts: Overview of Caching

Before diving into specific technologies, we need to clarify a few core concepts. To help you understand, we'll use a "student's backpack" as an analogy for a caching system.Before diving into specific technologies, we need to clarify a few core concepts. To help you understand, we'll use a "student's backpack" as an analogy for a caching system.

2.1 Understanding Core Caching Concepts Through the "Backpack Analogy"2.1 Understanding Core Caching Concepts Through the "Backpack Analogy"

Imagine you're a student who needs to look up various references every day. This process is strikingly similar to how a caching system works:Imagine you're a student who needs to look up various references every day. This process is strikingly similar to how a caching system works:

2.2 Cache Hit vs. Cache Miss2.2 Cache Hit vs. Cache Miss

The performance difference between a cache hit and a cache miss is enormous. Let's look at the concrete numbers:The performance difference between a cache hit and a cache miss is enormous. Let's look at the concrete numbers:

2.3 The Cache Lifecycle2.3 The Cache Lifecycle

A cache entry goes through a complete lifecycle from creation to destruction. Understanding this process is crucial for designing caching systems.A cache entry goes through a complete lifecycle from creation to destruction. Understanding this process is crucial for designing caching systems.

Four phases:Four phases:

Phase 1: WritePhase 1: Write

• Active write: Preload hot data into the cache at system startup (cache preheating)Active write: Preload hot data into the cache at system startup (cache preheating)
• Lazy load: Load from the database and write to cache on first access (most common)Lazy load: Load from the database and write to cache on first access (most common)

Phase 2: Hit / MissPhase 2: Hit / Miss

• Every request checks the cache firstEvery request checks the cache first
• Hit → return directly; miss → query the databaseHit → return directly; miss → query the database

Phase 3: ExpirationPhase 3: Expiration

• TTL (Time To Live): Set a lifespan for the cache entry (e.g., 30 minutes)TTL (Time To Live): Set a lifespan for the cache entry (e.g., 30 minutes)
• Upon expiration, the cache entry is automatically invalidated; the next access must reloadUpon expiration, the cache entry is automatically invalidated; the next access must reload

Phase 4: EvictionPhase 4: Eviction

• Cache space is limited — when full, old data must be deletedCache space is limited — when full, old data must be deleted
• Common eviction strategies:Common eviction strategies:
• LRU (Least Recently Used): Evict the data that hasn't been accessed for the longest time (most common)LRU (Least Recently Used): Evict the data that hasn't been accessed for the longest time (most common)
• LFU (Least Frequently Used): Evict the data with the lowest access frequencyLFU (Least Frequently Used): Evict the data with the lowest access frequency
• FIFO (First In First Out): Evict the earliest-written dataFIFO (First In First Out): Evict the earliest-written data

👇 Try it yourself:👇 Try it yourself:

The demo below illustrates the cache lifecycle. Click "Add Cache" and observe how cache entries go through the full process of write, hit, expiration, and eviction:The demo below illustrates the cache lifecycle. Click "Add Cache" and observe how cache entries go through the full process of write, hit, expiration, and eviction:

------

3. The Evolution of Caching: From Single-Machine to Distributed3. The Evolution of Caching: From Single-Machine to Distributed

Now that we've covered the concepts, let's look at a real case study: how an e-commerce system evolved from "no cache" to a "multi-level caching architecture." This case study will give you a more intuitive understanding of why cache design matters.Now that we've covered the concepts, let's look at a real case study: how an e-commerce system evolved from "no cache" to a "multi-level caching architecture." This case study will give you a more intuitive understanding of why cache design matters.

3.1 Stage 1: The No-Cache Era — Database Running Naked3.1 Stage 1: The No-Cache Era — Database Running Naked

Background: In the early days, with only a few hundred users, all requests hit the database directly with no caching layer.Background: In the early days, with only a few hundred users, all requests hit the database directly with no caching layer.

Tech stack:Tech stack:

• Database: MySQLDatabase: MySQL
• No cache: no Redis, no local cacheNo cache: no Redis, no local cache

System architecture:System architecture:

User Request → Application Server → MySQL Database

Characteristics of this stage:Characteristics of this stage:

• ✅ Pros: Simple architecture, fast to develop✅ Pros: Simple architecture, fast to develop
• ❌ Cons: Heavy database load, poor performance, collapses beyond a thousand users❌ Cons: Heavy database load, poor performance, collapses beyond a thousand users

This "running naked" model works when users < 1,000, but as the user base grows to 10,000 or 100,000, the database begins to crash frequently, and the team urgently needs to introduce caching.This "running naked" model works when users < 1,000, but as the user base grows to 10,000 or 100,000, the database begins to crash frequently, and the team urgently needs to introduce caching.

3.2 Stage 2: Introducing Redis Cache — 10× Performance Improvement3.2 Stage 2: Introducing Redis Cache — 10× Performance Improvement

Background: Users grew to 10,000; the database couldn't keep up. The team decided to introduce Redis as a caching layer.Background: Users grew to 10,000; the database couldn't keep up. The team decided to introduce Redis as a caching layer.

Tech stack:Tech stack:

• Database: MySQLDatabase: MySQL
• Cache: Redis (single instance)Cache: Redis (single instance)

System architecture:System architecture:

User Request → Application Server → Redis Cache (query DB only on miss) → MySQL Database

Characteristics of this stage:Characteristics of this stage:

• ✅ Pros: 10× performance improvement, 90% reduction in database load✅ Pros: 10× performance improvement, 90% reduction in database load
• ❌ Cons: Redis single point of failure, potential cache-database inconsistency❌ Cons: Redis single point of failure, potential cache-database inconsistency

After introducing Redis, system performance improved dramatically, but new problems emerged. The team began researching how to solve these cache-related issues.After introducing Redis, system performance improved dramatically, but new problems emerged. The team began researching how to solve these cache-related issues.

3.3 Stage 3: Multi-Level Cache Architecture — Another 5× Performance Boost3.3 Stage 3: Multi-Level Cache Architecture — Another 5× Performance Boost

Background: Users grew to 100,000. Even Redis caching started becoming a bottleneck (single-instance Redis QPS caps at ~100,000). The team decided to introduce multi-level caching.Background: Users grew to 100,000. Even Redis caching started becoming a bottleneck (single-instance Redis QPS caps at ~100,000). The team decided to introduce multi-level caching.

Tech stack:Tech stack:

• L1 Cache: Application-local cache (Caffeine)L1 Cache: Application-local cache (Caffeine)
• L2 Cache: Redis clusterL2 Cache: Redis cluster
• Database: MySQL primary-replica clusterDatabase: MySQL primary-replica cluster

System architecture:System architecture:

User Request → CDN Cache (static assets) → Application Server ↓ L1: Local Cache (Caffeine) → Miss → L2: Redis → Miss → MySQL

Characteristics of this stage:Characteristics of this stage:

• ✅ Pros: Ultimate performance (local cache takes only ~0.1 ms), high availability (Redis downtime doesn't affect hot data)✅ Pros: Ultimate performance (local cache takes only ~0.1 ms), high availability (Redis downtime doesn't affect hot data)
• ❌ Cons: Complex architecture, difficult to guarantee consistency across cache tiers❌ Cons: Complex architecture, difficult to guarantee consistency across cache tiers

Multi-level cache architectures are widely used by large internet companies (like Taobao, JD.com) and can support millions of QPS.Multi-level cache architectures are widely used by large internet companies (like Taobao, JD.com) and can support millions of QPS.

3.4 Cache Architecture Evolution Panorama3.4 Cache Architecture Evolution Panorama

------

4. The Three Classic Cache Problems: Penetration, Breakdown, and Avalanche4. The Three Classic Cache Problems: Penetration, Breakdown, and Avalanche

In practice, caching introduces three classic problems. If you don't understand them, your system could suddenly collapse at some point. Let's use everyday analogies to understand these problems.In practice, caching introduces three classic problems. If you don't understand them, your system could suddenly collapse at some point. Let's use everyday analogies to understand these problems.

4.1 Cache Penetration: Querying Non-Existent Data4.1 Cache Penetration: Querying Non-Existent Data

Problem definition: Querying data that doesn't exist (e.g., id=-1). It's not in the cache (because it was never stored), and it's not in the database — so every request punches straight through to the database.Problem definition: Querying data that doesn't exist (e.g., id=-1). It's not in the cache (because it was never stored), and it's not in the database — so every request punches straight through to the database.

Real-world scenarios:Real-world scenarios:

• Malicious attackers construct massive numbers of non-existent IDs for querying (e.g., id=-1, id=999999999)Malicious attackers construct massive numbers of non-existent IDs for querying (e.g., id=-1, id=999999999)
• Crawlers traversing non-existent resource paths (e.g., /api/products/invalid-id)Crawlers traversing non-existent resource paths (e.g., /api/products/invalid-id)
• Business logic errors leading to queries for invalid dataBusiness logic errors leading to queries for invalid data

Solution 1: Cache Null ObjectsSolution 1: Cache Null Objects

async function getProduct(productId) { const cacheKey = `product:${productId}` // 1. Check cache first const cached = await redis.get(cacheKey) if (cached !== null) { // Note: cached could be the string "null" if (cached === 'null') { // Cached "null object" — the database doesn't have this data return null } return JSON.parse(cached) } // 2. Query the database const product = await db.query( 'SELECT * FROM products WHERE id = ?', [productId] ) // 3. Even if the database has nothing, cache "null" with a short TTL (e.g., 5 minutes) if (!product) { await redis.setex(cacheKey, 300, 'null') return null } // 4. Data found, cache normally await redis.setex(cacheKey, 1800, JSON.stringify(product)) return product }

Solution 2: Bloom FilterSolution 2: Bloom Filter

A Bloom filter is a tool for "quickly determining whether data exists" — it's like a "super index":A Bloom filter is a tool for "quickly determining whether data exists" — it's like a "super index":

// Using a Bloom filter const { BloomFilter } = require('bloom-filters') // Initialize Bloom filter (assuming up to 1 million product IDs) const bloomFilter = new BloomFilter(1000000, 0.01) // 1% false positive rate // At system startup, add all product IDs to the Bloom filter async function initBloomFilter() { const allIds = await db.query('SELECT id FROM products') allIds.forEach(row => { bloomFilter.add(row.id) }) } // Before querying a product, check with the Bloom filter first async function getProduct(productId) { // 1. Check with Bloom filter first if (!bloomFilter.has(productId)) { // Definitely doesn't exist — return null, no need to query the database console.log('Bloom filter intercept: product does not exist') return null } // 2. Bloom filter says "might exist" — check cache const cached = await redis.get(`product:${productId}`) if (cached) { return JSON.parse(cached) } // 3. Cache miss — query database const product = await db.query( 'SELECT * FROM products WHERE id = ?', [productId] ) if (!product) { // Bloom filter false positive (very low probability) — actually doesn't exist await redis.setex(`product:${productId}`, 300, 'null') return null } // 4. Data found, write to cache await redis.setex(`product:${productId}`, 1800, JSON.stringify(product)) return product }

4.2 Cache Breakdown: Hot Data Expiration4.2 Cache Breakdown: Hot Data Expiration

Problem definition: A piece of hot data (like a trending product or hot news) expires in the cache (TTL runs out). At that moment, a flood of concurrent requests all arrive simultaneously and all query the database, causing a sudden spike in database load.Problem definition: A piece of hot data (like a trending product or hot news) expires in the cache (TTL runs out). At that moment, a flood of concurrent requests all arrive simultaneously and all query the database, causing a sudden spike in database load.

Real-world scenarios:Real-world scenarios:

• A trending hashtag on Weibo expires — tens of thousands visit simultaneouslyA trending hashtag on Weibo expires — tens of thousands visit simultaneously
• Celebrity gossip news cache expires — fans swarm inCelebrity gossip news cache expires — fans swarm in
• Flash sale inventory data expires at the start of the eventFlash sale inventory data expires at the start of the event

Solution 1: Mutex LockSolution 1: Mutex Lock

async function getProduct(productId) { const cacheKey = `product:${productId}` // 1. Check cache first const cached = await redis.get(cacheKey) if (cached) { return JSON.parse(cached) } // 2. Cache miss — acquire distributed lock const lockKey = `lock:${productId}` const lock = await redis.set(lockKey, '1', 'NX', 'EX', 10) // 10-second lock if (lock === 'OK') { // 3. Lock acquired — query database console.log('Lock acquired, querying database') const product = await db.query( 'SELECT * FROM products WHERE id = ?', [productId] ) // 4. Write to cache await redis.setex(cacheKey, 1800, JSON.stringify(product)) // 5. Release lock await redis.del(lockKey) return product } else { // 6. Lock not acquired — wait 50ms and retry console.log('Lock not acquired, waiting and retrying') await new Promise(resolve => setTimeout(resolve, 50)) return getProduct(productId) // Recursive retry } }

Solution 2: Logical ExpirationSolution 2: Logical Expiration

async function getProduct(productId) { const cacheKey = `product:${productId}` // 1. Check cache const cached = await redis.get(cacheKey) if (cached) { const data = JSON.parse(cached) // 2. Check logical expiration time if (Date.now() < data.expireTime) { // Not expired — return directly return data.product } else { // 3. Logically expired — rebuild cache asynchronously while returning old data console.log('Logically expired, rebuilding cache asynchronously') rebuildCacheAsync(productId) // Async rebuild return data.product // Return old data } } // 4. Cache doesn't exist (first load) — query database synchronously const product = await db.query( 'SELECT * FROM products WHERE id = ?', [productId] ) // 5. Write to cache (including logical expiration time) const cacheData = { product: product, expireTime: Date.now() + 30 * 60 * 1000 // Logically expires in 30 minutes } await redis.set(cacheKey, JSON.stringify(cacheData)) return product } // Async cache rebuild async function rebuildCacheAsync(productId) { const lockKey = `rebuild:${productId}` const lock = await redis.set(lockKey, '1', 'NX', 'EX', 10) if (lock === 'OK') { console.log('Async cache rebuild started') const product = await db.query( 'SELECT * FROM products WHERE id = ?', [productId] ) const cacheData = { product: product, expireTime: Date.now() + 30 * 60 * 1000 } await redis.set(`product:${productId}`, JSON.stringify(cacheData)) await redis.del(lockKey) console.log('Async cache rebuild complete') } }

4.3 Cache Avalanche: Mass Simultaneous Expiration4.3 Cache Avalanche: Mass Simultaneous Expiration

Problem definition: A large amount of cached data expires at the same moment (or Redis goes down), causing all requests to punch through to the database simultaneously and overwhelm it instantly.Problem definition: A large amount of cached data expires at the same moment (or Redis goes down), causing all requests to punch through to the database simultaneously and overwhelm it instantly.

Real-world scenarios:Real-world scenarios:

• After a system restart, all caches rebuild from scratch with identical TTLs (e.g., 30 minutes)After a system restart, all caches rebuild from scratch with identical TTLs (e.g., 30 minutes)
• A scheduled job bulk-refreshes caches with the same expiration timeA scheduled job bulk-refreshes caches with the same expiration time
• The cache service (Redis) goes down or experiences a network partitionThe cache service (Redis) goes down or experiences a network partition

Solution 1: Random TTLSolution 1: Random TTL

async function getProduct(productId) { const cacheKey = `product:${productId}` const cached = await redis.get(cacheKey) if (cached) { return JSON.parse(cached) } const product = await db.query( 'SELECT * FROM products WHERE id = ?', [productId] ) // Key: add a random offset (±5 minutes) to the base TTL (30 minutes) const baseTTL = 1800 // 30 minutes const randomOffset = Math.floor(Math.random() * 600) - 300 // -5 to +5 minutes const finalTTL = baseTTL + randomOffset console.log(`Cache TTL: ${finalTTL} seconds (${Math.floor(finalTTL / 60)} minutes)`) await redis.setex(cacheKey, finalTTL, JSON.stringify(product)) return product }

Solution 2: Cache PreheatingSolution 2: Cache Preheating

// At system startup, proactively load hot data into the cache async function cacheWarmup() { console.log('Starting cache preheating...') // 1. Query the top 1,000 hottest products (sorted by view count) const hotProducts = await db.query(` SELECT * FROM products ORDER BY view_count DESC LIMIT 1000 `) // 2. Batch-write to Redis for (const product of hotProducts) { const cacheKey = `product:${product.id}` const ttl = 1800 + Math.floor(Math.random() * 600) // 30 minutes ± 5 minutes await redis.setex(cacheKey, ttl, JSON.stringify(product)) } console.log(`Cache preheating complete, loaded ${hotProducts.length} hot products`) } // Execute at application startup cacheWarmup()

Solution 3: Circuit Breaker with FallbackSolution 3: Circuit Breaker with Fallback

// Use a circuit breaker to protect the database const CircuitBreaker = require('opossum') // Configure the circuit breaker const dbQueryBreaker = new CircuitBreaker( async (productId) => { return await db.query('SELECT * FROM products WHERE id = ?', [productId]) }, { timeout: 3000, // 3-second timeout errorThresholdPercentage: 50, // Trip when error rate exceeds 50% resetTimeout: 30000 // Attempt recovery after 30 seconds } ) // Fallback handling when the circuit is open dbQueryBreaker.fallback(() => { console.log('Database circuit open, returning fallback data') return { id: productId, name: 'Service is busy, please try again later', status: 'degraded' } }) async function getProduct(productId) { const cacheKey = `product:${productId}` const cached = await redis.get(cacheKey) if (cached) { return JSON.parse(cached) } // Query database through the circuit breaker const product = await dbQueryBreaker.fire(productId) if (product.status === 'degraded') { return product // Return fallback data } await redis.setex(cacheKey, 1800, JSON.stringify(product)) return product }

👇 Try it yourself:👇 Try it yourself:

The demo below compares the scenarios and solutions for cache penetration, breakdown, and avalanche:The demo below compares the scenarios and solutions for cache penetration, breakdown, and avalanche:

------

5. Cache Consistency Strategies: Keeping Cache and Database in Sync5. Cache Consistency Strategies: Keeping Cache and Database in Sync

A cache is, by nature, a copy of data. There's always a window of inconsistency between the copy and the original data (the database). How to control this window is the core challenge of cache design.A cache is, by nature, a copy of data. There's always a window of inconsistency between the copy and the original data (the database). How to control this window is the core challenge of cache design.

5.1 Motivation for Caching and Database Become Inconsistent5.1 Motivation for Caching and Database Become Inconsistent

A real concurrency scenario:A real concurrency scenario:

The problem: At time T2, Thread B reads the old value 20 from the cache, while the database already has 25. This is cache inconsistency.The problem: At time T2, Thread B reads the old value 20 from the cache, while the database already has 25. This is cache inconsistency.

5.2 Best Practice: Update the Database First, Then Delete the Cache5.2 Best Practice: Update the Database First, Then Delete the Cache

Standard flow:Standard flow:

// Update product information async function updateProduct(productId, updateData) { // 1. Update the database first await db.query( 'UPDATE products SET name = ?, price = ? WHERE id = ?', [updateData.name, updateData.price, productId] ) // 2. Then delete the cache (not update it!) await redis.del(`product:${productId}`) // 3. On the next query, cache miss triggers automatic reload of the latest data console.log('Update complete, cache deleted') }

5.3 Delayed Double-Delete: Consistency Guarantee for Extreme Scenarios5.3 Delayed Double-Delete: Consistency Guarantee for Extreme Scenarios

Scenario: Under high concurrency, even "update DB first, then delete cache" has a tiny probability of inconsistency. Delayed double-delete maximizes consistency through two deletions.Scenario: Under high concurrency, even "update DB first, then delete cache" has a tiny probability of inconsistency. Delayed double-delete maximizes consistency through two deletions.

Flow:Flow:

1. Delete cache 2. Update database 3. Wait for a period (e.g., 500ms) 4. Delete cache again

async function updateProduct(productId, updateData) { const cacheKey = `product:${productId}` // 1. First cache deletion await redis.del(cacheKey) // 2. Update database await db.query( 'UPDATE products SET name = ?, price = ? WHERE id = ?', [updateData.name, updateData.price, productId] ) // 3. Wait 500ms (let other threads' queries complete) await new Promise(resolve => setTimeout(resolve, 500)) // 4. Second cache deletion (remove old data possibly loaded by other threads) await redis.del(cacheKey) console.log('Delayed double-delete complete, data synced') }

Comparison of three consistency strategies:Comparison of three consistency strategies:

👇 Try it yourself:👇 Try it yourself:

The demo below compares the effects of the three consistency strategies. Click "Update Data" and observe how cache and database consistency changes:The demo below compares the effects of the three consistency strategies. Click "Update Data" and observe how cache and database consistency changes:

------

6. Hands-On: Building a Complete Caching System6. Hands-On: Building a Complete Caching System

Now that we've covered the principles, let's look at a real case study: how to design a complete caching system for an e-commerce product detail page.Now that we've covered the principles, let's look at a real case study: how to design a complete caching system for an e-commerce product detail page.

6.1 Business Scenario Analysis6.1 Business Scenario Analysis

Requirement: Users visit a product detail page that needs to display basic product info, price, inventory, reviews, and more.Requirement: Users visit a product detail page that needs to display basic product info, price, inventory, reviews, and more.

Characteristics:Characteristics:

• Read-heavy, write-light: 100 reads for every 1 write (100:1 read/write ratio)Read-heavy, write-light: 100 reads for every 1 write (100:1 read/write ratio)
• Hotspot concentration: 20% of products drive 80% of trafficHotspot concentration: 20% of products drive 80% of traffic
• Data complexity: Basic product info + price + inventory + review aggregatesData complexity: Basic product info + price + inventory + review aggregates
• Consistency requirements: Price and inventory require strong consistency; everything else can be eventually consistentConsistency requirements: Price and inventory require strong consistency; everything else can be eventually consistent

Performance targets:Performance targets:

• P99 response time < 100ms (99% of requests return within 100ms)P99 response time < 100ms (99% of requests return within 100ms)
• Peak database QPS < 5,000Peak database QPS < 5,000
• Cache hit ratio > 95%Cache hit ratio > 95%

6.2 Architecture Design6.2 Architecture Design

Multi-level cache architecture:Multi-level cache architecture:

User Request ↓ CDN Cache (static assets: images, CSS, JS) ↓ Miss Nginx Local Cache (aggregated product info) ↓ Miss Application Server ↓ ├─ L1: Local Cache (Caffeine, hot products) │ ↓ Miss ├─ L2: Redis Cache (all product data) │ ↓ Miss └─ L3: MySQL Database (complete dataset)

6.3 Core Code Implementation6.3 Core Code Implementation

Complete multi-level cache implementation (simplified):Complete multi-level cache implementation (simplified):

const caffeine = require('caffeine') // L1: Local cache (30-second TTL) const localCache = new caffeine.Cache({ max: 1000, ttl: 30, }) // Get product details (multi-level cache) async function getProduct(productId) { const cacheKey = `product:${productId}` // L1: Local cache (~0.1 ms) const localCached = localCache.get(cacheKey) if (localCached) { console.log('L1 hit') return localCached } // L2: Redis cache (~1 ms) const redisCached = await redis.get(cacheKey) if (redisCached) { console.log('L2 hit, backfilling L1') const product = JSON.parse(redisCached) localCache.set(cacheKey, product) return product } // L3: Database (~10 ms, with distributed lock to prevent breakdown) const lockKey = `lock:${productId}` const lock = await redis.set(lockKey, '1', 'NX', 'EX', 10) if (lock === 'OK') { console.log('L3 hit, querying database') const product = await db.query( 'SELECT * FROM products WHERE id = ?', [productId] ) if (product) { // Write to Redis (30 minutes + random TTL) const ttl = 1800 + Math.floor(Math.random() * 600) - 300 await redis.setex(cacheKey, ttl, JSON.stringify(product)) // Backfill local cache localCache.set(cacheKey, product) } await redis.del(lockKey) return product } else { // Lock not acquired — wait and retry await new Promise(resolve => setTimeout(resolve, 50)) return getProduct(productId) } } // Update product info (update DB first, then delete cache) async function updateProduct(productId, updateData) { const cacheKey = `product:${productId}` // 1. Update database await db.query( 'UPDATE products SET name = ?, price = ? WHERE id = ?', [updateData.name, updateData.price, productId] ) // 2. Delete local cache localCache.del(cacheKey) // 3. Delete Redis cache await redis.del(cacheKey) console.log('Update complete, cache deleted') }

👇 Try it yourself:👇 Try it yourself:

The demo below shows the complete workflow of a multi-level caching system. Click "Query Product" and observe how requests flow through the cache tiers:The demo below shows the complete workflow of a multi-level caching system. Click "Query Product" and observe how requests flow through the cache tiers:

------

7. Summary and Learning Path7. Summary and Learning Path

7.1 Core Knowledge Review7.1 Core Knowledge Review

7.2 Recommended Learning Path7.2 Recommended Learning Path

Phase 1: Understand the Principles (1–2 days)Phase 1: Understand the Principles (1–2 days)

• Grasp the essence of caching (data copies, trading space for time)Grasp the essence of caching (data copies, trading space for time)
• Understand core concepts: hit ratio, TTL, evictionUnderstand core concepts: hit ratio, TTL, eviction
• Learn the performance differences between storage media (memory vs. disk)Learn the performance differences between storage media (memory vs. disk)

Phase 2: Master the Basics (2–3 days)Phase 2: Master the Basics (2–3 days)

• Learn to use Redis for caching (SET, GET, SETEX commands)Learn to use Redis for caching (SET, GET, SETEX commands)
• Implement simple cache read/write logic (check cache first, query database on miss)Implement simple cache read/write logic (check cache first, query database on miss)
• Understand why you "delete cache on update" rather than "update cache"Understand why you "delete cache on update" rather than "update cache"

Phase 3: Solve the Classic Problems (1 week)Phase 3: Solve the Classic Problems (1 week)

• Solve cache penetration: implement a Bloom filter or cache null objectsSolve cache penetration: implement a Bloom filter or cache null objects
• Solve cache breakdown: implement a mutex lock or logical expirationSolve cache breakdown: implement a mutex lock or logical expiration
• Solve cache avalanche: implement random TTL and cache preheatingSolve cache avalanche: implement random TTL and cache preheating

Phase 4: Multi-Level Caching (1–2 weeks)Phase 4: Multi-Level Caching (1–2 weeks)

• Introduce local caching (Caffeine/Guava)Introduce local caching (Caffeine/Guava)
• Design a local cache + Redis two-tier architectureDesign a local cache + Redis two-tier architecture
• Handle consistency issues across cache tiersHandle consistency issues across cache tiers

Phase 5: Production-Grade Practice (ongoing)Phase 5: Production-Grade Practice (ongoing)

• Design a complete product detail page caching systemDesign a complete product detail page caching system
• Set up monitoring (cache hit ratio, response time)Set up monitoring (cache hit ratio, response time)
• Perform load testing and performance tuningPerform load testing and performance tuning