Caching & performance
Fast is a feature. Stale is a bug.

A cache is the cheapest performance win you’ll ever ship, and the most common source of “but I just changed it, why is it still showing the old value?”. Good answers here always come with a staleness budget: how out-of-date each piece of data is allowed to be.

30-second answer: cache-aside (most common): check the cache, on a miss read the database and fill the cache; on a write, update the database and delete the key. Read-through: the cache loads from the database itself. Write-through: write cache and database together. Write-back: write the cache, flush to the database later. Write-around: write only the database; the cache fills on reads.

Product getProduct(String id) {
    Product p = redis.get(key(id));
    if (p != null) return p;
    p = db.loadProduct(id);
    redis.set(key(id), p, Duration.ofMinutes(5).plusSeconds(rand(0, 60)));  // TTL + jitter
    return p;
}

void updateProduct(Product p) {
    db.save(p);
    redis.delete(key(p.id()));   // delete, don't set
}

30-second answer: combine a TTL as a safety net with event-driven invalidation for freshness, and choose the staleness budget per kind of data. For correctness-critical reads (a balance at payment time), skip the cache.

• TTL with jitter, so keys don’t all expire together.
• Delete on write (cache-aside).
• Change-data-capture invalidation: database log → stream → invalidator. It catches every write path, including scripts and other services.
• Versioned keys: product:{id}:v{n}. A write bumps the version; old keys are never read again and just age out.
• Pub/sub to invalidate in-process caches across many nodes.
• Two levels: in-process (L1) → Redis (L2) → database. L1 needs a short TTL or a broadcast.

30-second answer: a CDN caches content on servers close to users, cutting latency and origin load, and adds DDoS protection, TLS and a WAF. Cache static assets aggressively with content-hashed filenames and max-age + immutable. Cache public, non-personal API responses briefly. Never cache personal or authenticated responses at a shared edge.

Headers to know:

• Cache-Control: public / private, max-age, s-maxage (shared caches), no-store, stale-while-revalidate.
• ETag for revalidation; Vary for responses that differ by encoding or language.
• Invalidate with purge APIs, or better, with versioned URLs so you never need to purge.

Takeaways: memory is about a thousand times faster than the network. Avoid chatty calls and N+1 patterns; batch, cache and parallelise. A cross-region call in the request path is very expensive.

1. Define the goal: which metric (p99 latency? throughput?) and what target.
2. Measure: percentiles, not averages, with a baseline under realistic load.
3. Find the bottleneck: traces (where does time go?), profilers and flame graphs, slow-query logs and EXPLAIN, GC logs, thread dumps.
4. Fix the biggest contributor first. Shaving a small step barely matters (Amdahl’s law).
5. Verify with a load test and production metrics, then add a regression alert.

• Cache-aside; delete on write; TTL + jitter.
• Staleness budget per data type; bypass the cache for money.
• Single-flight for stampedes, negative caching for penetration, jitter for avalanches.
• CDN: hashed static files cached forever; nothing personal at the edge.
• Memory ≪ network; batch and cache.
• Measure → profile → fix the biggest thing → verify → alert.