Caching Strategies and CDN

# CHAPTER 7

Caching Strategies and CDN #

1. Chapter Introduction #

2. What is a Cache? #

• Databases store data on Disk (SSD/HDD) -> Persistent but slow.

• Caches store data in Memory (RAM) -> Ephemeral but lightning fast.

3. Where to Cache? #

1. 1. Client/Browser Cache: The browser stores logos and CSS files locally so it doesn't have to download them again.

1. 2. CDN (Content Delivery Network): Geographically distributed servers caching static media globally.

1. 3. Web Server Cache: Reverse proxies (Nginx) caching HTML pages.

1. 4. Application/Database Cache (Redis/Memcached): Caching the raw JSON data returned from slow database queries.

4. Distributed Caches: Redis vs. Memcached #

• Memcached: Simple, multi-threaded, purely in-memory. Great for simple string caching.

• Redis: The industry standard. Single-threaded, but supports complex data structures (Lists, Sets, Hashes) and offers persistence (saving snapshots to disk). *When in doubt, say Redis.*

5. Cache Reading Strategies #

1. 1. The app asks the Cache for the data.

1. 2. Cache Hit: Data is found and returned instantly.

1. 3. Cache Miss: Data is not found. The app queries the Database, receives the data, saves a copy in the Cache, and returns it to the user.

6. Cache Writing Strategies #

1. 1. Write-Through: App writes data to the Cache AND the Database simultaneously.

1. 2. Write-Around: App writes directly to the Database, bypassing the cache.

1. 3. Write-Back: App writes ONLY to the Cache (fast). The cache asynchronously syncs to the database later.

7. Cache Invalidation (The Hardest Problem) #

1. 1. TTL (Time To Live): Assign an expiration time to the cached item (e.g., 5 minutes). It automatically deletes itself.

1. 2. Active Invalidation: When the App updates the DB, it explicitly sends a DELETE command to the Cache for that specific key.

8. CDN (Content Delivery Network) #

9. Real-World Scenario: The Viral Tweet #

10. Mini Project: Cache a User Profile #

function getUserProfile(userId) {
   // 1. Check Cache
   let user = Redis.get("user:" + userId);
   if (user != null) {
      return user; // Cache Hit
   }
   // 2. Cache Miss: Query DB
   user = Database.query("SELECT * FROM Users WHERE id = " + userId);
   // 3. Save to Cache with 1 hour TTL
   Redis.set("user:" + userId, user, TTL=3600);
   return user;
}

11. Common Mistakes #

• Caching everything: RAM is expensive. Do not cache data that is rarely accessed.

• Ignoring the Thundering Herd Problem: If a popular cached item expires (TTL ends), 10,000 requests might hit the database simultaneously to regenerate it before the new cache is set. (Fix: Use mutex locks).

12. Best Practices #

• Eviction Policies: What happens when Redis runs out of RAM? Configure an eviction policy like LRU (Least Recently Used), which automatically deletes the data that hasn't been requested in the longest time to make room for new data.

13. MCQs #

14. Interview Questions #

• Q: "We have a news website. The homepage queries the top 10 articles from the database. Traffic is spiking and the DB is at 90% CPU. Walk me through exactly how you would implement a caching layer to fix this."

15. FAQs #

• Q: Should I cache API responses or database queries?

16. Summary #

17. Next Chapter Recommendation #