Caching & CDNs

#Introduction

A cache stores copies of frequently used data in fast storage (memory) so future requests are served quickly without hitting the slower source (a database or another service). Caching is usually the single biggest performance win in read-heavy systems.

"There are only two hard things in computer science: cache invalidation and naming things." — Phil Karlton

#Where Caches Live

#Caching Strategies

Cache-Aside (Lazy Loading) — the Most Common

The application manages the cache:

public Product getProduct(long id) {
    Product cached = redis.get("product:" + id);
    if (cached != null) return cached;                       // hit
    Product product = productRepository.findById(id).orElseThrow();
    redis.set("product:" + id, product, Duration.ofMinutes(10));   // miss → populate
    return product;
}

On writes, update the database, then delete the cache key so the next read reloads fresh data.

Read-Through

The cache sits in front of the database and loads missing entries itself (the cache library calls a loader). Same behaviour as cache-aside, but the logic lives in the cache layer.

Write-Through

Every write goes to the cache and the database synchronously.

Write-Behind (Write-Back)

Writes go to the cache immediately and are flushed to the database asynchronously.

Refresh-Ahead

Proactively reload popular entries before they expire, so users never hit a miss for hot keys.

#Invalidation and TTL

Cached data becomes stale when the source changes. Options:

• TTL (time to live) — entries expire after a set time. Simple and always worth setting as a safety net.
• Delete on write — remove the key when the data changes (cache-aside).
• Event-driven invalidation — services publish change events; caches delete or update the affected keys.
• Versioned keys — product:42:v7; a new version makes old entries irrelevant.

#Eviction Policies

When memory is full, something must go:

Redis is configured with maxmemory and a policy such as allkeys-lru or allkeys-lfu.

#Cache Problems

#Local vs Distributed Cache

A two-level cache — Caffeine in front of Redis — combines both: very fast hot reads, shared consistency for the rest.

#Caching in Spring Boot

@SpringBootApplication
@EnableCaching
public class CatalogApplication { }

@Service
public class ProductService {

    @Cacheable(value = "products", key = "#id")
    public Product getProduct(long id) {
        return productRepository.findById(id).orElseThrow();   // runs only on a cache miss
    }

    @CacheEvict(value = "products", key = "#product.id")
    public Product update(Product product) {
        return productRepository.save(product);
    }
}

spring:
  cache:
    type: redis
    redis:
      time-to-live: 10m
  data:
    redis:
      host: localhost
      port: 6379

@Cacheable, @CachePut and @CacheEvict work through Spring proxies — calls from inside the same class bypass them.

#Content Delivery Networks (CDNs)

A CDN is a network of edge servers around the world that cache content close to users:

• Serves static assets, images, video and downloads — and increasingly cacheable API responses.
• Reduces latency, origin load and bandwidth costs; absorbs traffic spikes and DDoS attacks.
• Controlled with Cache-Control headers (max-age, s-maxage, stale-while-revalidate) and versioned file names (app.3f9a1c.js) so updates are picked up immediately.

#What Not to Cache

• Data that must always be exact and current — account balances at payment time, stock at final checkout.
• Highly personalised responses (or cache them per user, carefully).
• Sensitive data in shared caches without encryption and access control.

#Key Takeaways

• Cache at every layer that helps: browser, CDN, gateway, application, database.
• Cache-aside with TTLs is the default; delete keys on write.
• Choose write-through, write-behind or refresh-ahead for specific needs.
• Handle stampedes, penetration, avalanches and hot keys deliberately.
• Combine local (Caffeine) and distributed (Redis) caches; use CDNs for static and media content.