Caching Strategies Explained: Redis, CDN & Application-Level Patterns

Caching is the practice of storing frequently accessed data in a fast storage layer to avoid expensive operations like database queries, API calls, or complex computations. In modern distributed systems, caching operates at multiple layers - from CPU caches to CDNs spanning the globe.

The fundamental principle is simple: store data closer to where it's needed and in faster storage mediums. A well-designed cache can transform a system that struggles under load into one that handles millions of requests per second. Companies like Netflix use multi-layer caching to serve 230 million subscribers worldwide with minimal latency.

Modern caching isn't just about speed - it's about system reliability. When your primary database goes down, a well-populated cache can keep your application running. This makes caching a critical component of distributed systems architecture and load balancing strategies.

Caching exists at every level of the computing stack, each with its own trade-offs and use cases:

• Browser Cache: Static assets (CSS, JavaScript, images) cached locally by web browsers
• CDN Cache: Content cached at edge servers globally for faster geographic delivery
• Reverse Proxy Cache: Tools like Nginx or Varnish cache responses at the web server level
• Application Cache: In-memory data structures within your application process
• Distributed Cache: Redis, Memcached, or Hazelcast for shared caching across servers
• Database Query Cache: MySQL query cache or PostgreSQL shared buffers
• Operating System Cache: File system and buffer cache managed by the OS

The key is understanding where bottlenecks occur in your system and implementing caching at the appropriate layer. A system design interview will often test your knowledge of these different caching layers and when to apply each one.

Redis and Memcached are the two dominant in-memory caching solutions, but they serve different use cases. Redis has largely won the popularity contest due to its rich data structures and persistence options, but Memcached still has performance advantages in specific scenarios.

Redis Advantages:

• Rich data types: strings, hashes, lists, sets, sorted sets, bitmaps, HyperLogLog
• Built-in persistence with RDB snapshots and AOF logging
• Pub/Sub messaging for real-time features
• Lua scripting for atomic operations
• Clustering and replication out of the box

Memcached Advantages:

• Lower memory overhead per key
• Simpler architecture means fewer failure modes
• Better multi-threading performance on many-core systems
• Deterministic memory usage with slab allocation

For most applications, Redis is the better choice due to its flexibility and ecosystem. Companies like GitHub use Redis to cache API responses, session data, and background job queues in a single system.

Content Delivery Networks (CDNs) cache static and dynamic content at edge locations worldwide, dramatically reducing latency for global users. Modern CDNs like AWS CloudFront, Cloudflare, and Azure CDN have evolved beyond simple file caching to support edge computing and dynamic content acceleration.

CDN Caching Strategies:

• Static Asset Caching: CSS, JavaScript, images with long TTLs (months to years)
• API Response Caching: Short-lived cache (minutes to hours) for API endpoints
• Edge-Side Includes (ESI): Cache page fragments with different TTLs
• Bandwidth Optimization: Compression, image optimization, minification at edge

Leading companies see dramatic improvements from CDN implementation. Shopify reports 40% faster page loads globally after implementing edge caching, while Discord uses Cloudflare to cache Discord.js library downloads, reducing origin server load by 90%.

For developers interested in cloud computing careers, understanding CDN configuration and optimization is increasingly important as more applications become globally distributed.

Application-level caching patterns determine how your code interacts with the cache layer. Choosing the right pattern affects performance, consistency, and complexity.

Cache-Aside (Lazy Loading)

The application manages the cache directly. On cache miss, load data from database and populate cache.

def get_user(user_id):
    # Try cache first
    user = redis.get(f"user:{user_id}")
    if user:
        return json.loads(user)
    
    # Cache miss - query database
    user = database.get_user(user_id)
    
    # Populate cache for next time
    redis.setex(f"user:{user_id}", 3600, json.dumps(user))
    return user

Write-Through Cache

Write to cache and database simultaneously. Ensures cache consistency but adds latency to writes.

def update_user(user_id, data):
    # Write to database first
    database.update_user(user_id, data)
    
    # Update cache immediately
    redis.setex(f"user:{user_id}", 3600, json.dumps(data))
    
    return data

Write-Behind (Write-Back) Cache

Write to cache immediately, asynchronously write to database later. Fastest writes but risk of data loss.

Refresh-Ahead Cache

Proactively refresh cache before expiration. Good for predictable access patterns but adds complexity.

Most production systems use cache-aside for reads and write-through for critical updates, implementing refresh-ahead for hot data. This hybrid approach balances performance with consistency requirements.

Phil Karlton famously said there are only two hard things in computer science: cache invalidation and naming things. Cache invalidation is challenging because you need to balance performance (keeping data cached) with consistency (ensuring fresh data).

Time-Based Expiration (TTL)

Set expiration times based on data characteristics. User profiles might cache for hours, while stock prices cache for seconds.

# Different TTLs for different data types
redis.setex("user:profile:123", 3600, user_data)  # 1 hour
redis.setex("stock:price:AAPL", 30, stock_data)   # 30 seconds
redis.setex("config:feature_flags", 300, flags)   # 5 minutes

Event-Based Invalidation

Invalidate cache when underlying data changes. Use message queues or database triggers to notify cache invalidation.

# Invalidate related caches when user updates
def on_user_update(user_id):
    redis.delete(f"user:{user_id}")
    redis.delete(f"user:posts:{user_id}")
    redis.delete(f"user:followers:{user_id}")

Cache Tags and Hierarchical Invalidation

Tag cache entries with metadata for bulk invalidation. When a user's data changes, invalidate all caches tagged with that user ID.

Versioned Caching

Include version numbers in cache keys. When data structure changes, increment version to effectively invalidate old entries.

The key insight is that cache invalidation strategy must be designed upfront, not retrofitted. Netflix's EVCache uses a combination of TTL and event-based invalidation to maintain consistency across their microservices architecture.

Cache performance monitoring is crucial for optimization and troubleshooting. Track these key metrics to understand cache effectiveness:

Core Cache Metrics:

• Hit Ratio: Percentage of requests served from cache (aim for 80-95%)
• Miss Ratio: Percentage of requests requiring database queries
• Eviction Rate: How often cache entries are removed to make space
• Average Response Time: P50, P95, P99 latencies for cache operations
• Memory Utilization: Cache memory usage and available capacity
• Connection Count: Active connections to cache servers

Redis-Specific Metrics:

# Monitor Redis performance with INFO command
redis-cli INFO stats | grep -E "(hits|misses|evicted)"

# Key metrics to watch:
# - keyspace_hits / (keyspace_hits + keyspace_misses) = hit ratio
# - evicted_keys = memory pressure indicator
# - expired_keys = TTL effectiveness

Application-Level Monitoring:

# Track cache performance in your application
class CacheMonitor:
    def __init__(self):
        self.hits = 0
        self.misses = 0
        self.errors = 0
    
    def record_hit(self):
        self.hits += 1
    
    def record_miss(self):
        self.misses += 1
    
    def hit_ratio(self):
        total = self.hits + self.misses
        return self.hits / total if total > 0 else 0

Tools like Grafana, Datadog, and New Relic offer pre-built dashboards for Redis and Memcached monitoring. For DevOps engineers, setting up comprehensive cache monitoring is a fundamental skill for maintaining high-performance systems.

Even experienced developers make caching mistakes that can hurt performance or cause data inconsistency. Here are the most common pitfalls and how to avoid them:

Cache Stampede

When a popular cache entry expires, multiple requests simultaneously try to regenerate it, overwhelming the database. Use cache locking or probabilistic refresh to prevent this.

# Prevent cache stampede with locking
def get_popular_data(key):
    data = cache.get(key)
    if data:
        return data
    
    # Try to acquire lock
    if cache.set(f"lock:{key}", "1", nx=True, ex=30):
        # We got the lock, compute the data
        data = expensive_database_query()
        cache.set(key, data, ex=3600)
        cache.delete(f"lock:{key}")
        return data
    else:
        # Another process is computing, wait and retry
        time.sleep(0.1)
        return cache.get(key) or fallback_data()

Hot Key Problem

A single cache key receives disproportionate traffic, creating a bottleneck. Distribute load using multiple cache instances or key sharding.

Memory Leaks from Poor Eviction

Setting TTLs too high or using PERSIST without cleanup leads to memory exhaustion. Monitor memory usage and implement appropriate eviction policies (LRU, LFU, volatile-lru).

Cache Consistency Issues

Updating database without invalidating cache leads to stale data. Always design your data update flow to include cache invalidation.

Over-Caching

Caching everything isn't always better. Data that changes frequently or is rarely accessed shouldn't be cached. Profile before optimizing.

Understanding these patterns is crucial for software engineering interviews and building reliable systems at scale.