CACHING

class LRUCache {
    private final int                          capacity;
    private final Map<int, Node>             map = new HashMap<>();
    private final Node                        head, tail; // Sentinel nodes
    private final ReentrantReadWriteLock      lock = new ReentrantReadWriteLock();

    public int get(int key) {
        lock.readLock().lock();
        try {
            Node n = map.get(key);
            if (n == null) return -1;
            moveToFront(n);  // Most-recently-used → head
            return n.val;
        } finally { lock.readLock().unlock(); }
    }

    public void put(int key, int val) {
        lock.writeLock().lock();
        try {
            if (map.containsKey(key)) {
                Node n = map.get(key); n.val = val; moveToFront(n);
            } else {
                Node n = new Node(key, val);
                map.put(key, n); addToFront(n);
                if (map.size() > capacity) evictTail(); // Remove LRU
            }
        } finally { lock.writeLock().unlock(); }
    }
}

Strategy 1: Delete on Write (safest, most common)
void updateProduct(id, product) {
    db.update(id, product);
    cache.delete("product:" + id);                          // ← DELETE, not SET
    cache.delete("products:category:" + product.categoryId); // ← invalidate list too
}
// Next read misses → fetches fresh from DB → repopulates
// Safe: avoids stale-write race condition

Strategy 2: Version-Based Keys (no explicit invalidation)
// Embed version in key. When data changes, bump version.
"product:42:v8"  →  "product:42:v9"   // old key naturally expires via TTL
// Application always reads latest version key.
// Great for: config data, feature flags, rarely-changing reference data

Strategy 3: Event-Based (CDC + Kafka)
// DB → Change Data Capture → Kafka → Cache Invalidation Service → Redis.delete(key)
DB_writes → Debezium/CDC → Kafka.publish(change_event) → CacheConsumer → cache.delete(key)
// Decoupled, real-time, works for distributed caches
// Cost: more infrastructure, event delivery latency, ordering guarantees needed

// Timeline of a nasty race:
Thread A: UPDATE product WHERE id=42        // starts write
Thread B: SELECT product WHERE id=42 → MISS   // reads old DB value (before A commits)
Thread A: cache.delete("product:42")         // invalidates
Thread B: cache.set("product:42", stale_val) // writes OLD value back!
// Result: cache holds stale data indefinitely until TTL expires 😱

Prevention:
  1. Use TTL as a safety net — even if stale, it expires eventually
  2. Use CAS (Compare-And-Set) — only write to cache if key still absent
     cache.setnx("product:42", freshVal)  ← only sets if key doesn't exist
  3. Use write lock during update:
     db.beginTransaction();
     db.update(id, product);
     cache.delete(key);        // ← delete INSIDE transaction before commit
     db.commit();

Strategy 1: Mutex/Lock on Miss (most reliable)
String get(String key) {
    String val = cache.get(key);
    if (val != null) return val;                 // HIT — fast path

    // MISS — exactly ONE thread refreshes; others wait
    boolean locked = cache.setnx("lock:"+key, "1", 10_seconds);
    if (locked) {
        try {
            val = db.get(key);
            cache.set(key, val, TTL);
            return val;
        } finally { cache.delete("lock:"+key); }
    } else {
        Thread.sleep(50); return get(key); // Retry — lock holder will populate cache
    }
}

Strategy 2: Probabilistic Early Expiration (PER)
// Before TTL expires, probabilistically start refreshing
if (ttlRemaining < -Math.log(random()) * recomputeTime) {
    refresh(); // One request triggers early refresh; others get (slightly stale) cached value
}

Strategy 3: Background Refresh (keep popular keys always warm)
// Scheduled job: refresh popular keys 30s before TTL expires
// Requires: popularity tracking (hit count per key)
scheduler.scheduleAtFixedRate(() -> hotKeys.forEach(k -> cache.refresh(k)), 30, 30, SECONDS);

// Per-user: 100 requests per 60-second window
// ZADD rate_limit:{userId} {timestamp_ms} {unique_request_id}
// ZRANGEBYSCORE rate_limit:{userId} (now-60000) now → requests in last 60s

boolean isAllowed(String userId, int limit, long windowMs) {
    long   now        = System.currentTimeMillis();
    long   windowStart = now - windowMs;
    String key        = "rate:" + userId;

    return redis.pipeline(pipe -> {
        pipe.zremrangebyscore(key, 0, windowStart);          // Remove expired entries
        pipe.zadd(key, now, UUID.randomUUID().toString()); // Add this request
        pipe.zcard(key);                                       // Count in window
        pipe.expire(key, windowMs / 1000);                    // Auto-expire key
    }).getCard() <= limit;
}
// ✅ Exact sliding window · ✅ Multi-server safe (shared Redis)
// Memory: O(requests in window) per user — scale with caution for large limits

// STATIC content (images, CSS, JS, fonts)
Cache-Control: max-age=31536000, immutable
// CDN caches for 1 year. Use hash-based filenames for cache busting.
app.js → app.8f3d92ab.js   // Content hash in filename → new deploy = new URL = fresh CDN cache

// DYNAMIC content (API responses, partially personalised pages)
Cache-Control: max-age=60, stale-while-revalidate=30
// CDN caches for 60s. During next 30s after expiry, serve stale while fetching fresh.
// Eliminates miss latency for CDN — no thundering herd at origin.

// PRIVATE content (user-specific responses)
Cache-Control: private, no-store
// CDN does NOT cache. Request always reaches origin. Each user's data is unique.

// Vary header — separate cache per encoding/format
Vary: Accept-Encoding
// CDN stores separate versions for gzip and uncompressed.