Caching

Implement production-grade multi-tier caching architecture for databases using Redis (distributed cache), in-memory caching (L1), and CDN (static assets) to reduce database load by 80-95%, improve query latency from 50ms to 1-5ms, and support horizontal scaling with cache-aside, write-through, and read-through patterns.

When to Use This Command

Use /caching when you need to:

• Reduce database load by caching frequently accessed data (80% hit rate)
• Improve query response times from 50-100ms to 1-5ms
• Handle traffic spikes without database scaling (cache absorbs load)
• Support read-heavy workloads with minimal database reads
• Implement distributed caching across multiple application servers
• Enable horizontal scaling with stateless application servers

DON'T use this when:

• Data changes frequently and cache hit rate would be <50%
• Application has strict real-time data requirements (< 1s staleness)
• Database is already fast enough (<10ms query latency)
• You lack cache invalidation strategy (stale data risk)
• Small dataset fits entirely in database memory (shared_buffers)
• Write-heavy workload (caching provides minimal benefit)

Design Decisions

This command implements multi-tier caching with intelligent invalidation because:

• L1 in-memory cache (1-5ms) for hot data per server
• L2 distributed Redis cache (5-10ms) shared across servers
• Cache-aside pattern provides fallback to database on miss
• TTL-based and event-based invalidation prevents stale data
• Write-through caching maintains consistency for critical data

Alternative considered: Read-through caching

• Simpler implementation (cache handles database queries)
• Less control over cache population strategy
• Not suitable when database schema differs from cached format
• Recommended for simple key-value lookups

Alternative considered: Database query result caching (pg_stat_statements)

• Built into PostgreSQL (no external dependencies)
• Limited to identical queries (parameter changes = cache miss)
• Cannot cache across multiple queries
• Recommended for development/small workloads only

Prerequisites

Before running this command:

1. Redis server deployed (standalone, Sentinel, or Cluster)
2. Understanding of cache invalidation needs (TTL vs event-driven)
3. Monitoring for cache hit rate and memory usage
4. Connection pooling configured for Redis clients
5. Fallback strategy for cache failures (graceful degradation)

Implementation Process

Step 1: Design Cache Key Strategy

Define hierarchical cache keys for easy invalidation (e.g., user:123:profile).

Step 2: Implement Cache-Aside Pattern

Check cache first, query database on miss, populate cache with result.

Step 3: Configure TTL and Eviction

Set appropriate TTL based on data freshness requirements and memory limits.

Step 4: Implement Invalidation Logic

Invalidate cache on data updates using event listeners or explicit invalidation.

Step 5: Monitor Cache Performance

Track hit rate, miss rate, latency, and memory usage with Prometheus/Grafana.

Output Format

The command generates:

• caching/redis_client.py - Redis connection pool and wrapper
• caching/cache_decorator.py - Python decorator for automatic caching
• caching/cache_invalidation.js - Event-driven invalidation logic
• caching/cache_monitoring.yml - Prometheus metrics and alerts
• caching/cache_warming.sql - SQL queries for cache preloading

Code Examples

Example 1: Python Multi-Tier Cache with Redis and In-Memory

#!/usr/bin/env python3
"""
Production-ready multi-tier caching system with L1 (in-memory) and
L2 (Redis) caches, automatic invalidation, and performance monitoring.
"""

import redis
import pickle
from typing import Optional, Callable, Any
from functools import wraps
from datetime import timedelta
import time
import logging
from cachetools import TTLCache
import hashlib
import json

logging.basicConfig(level=logging.INFO)
…

Example 2: Cache Warming and Preloading

#!/usr/bin/env python3
"""
Cache warming strategy to preload hot data before traffic hits.
Reduces cold start latency and improves cache hit rate.
"""

import psycopg2
from concurrent.futures import ThreadPoolExecutor, as_completed
import time
import logging

logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)


class CacheWarmer:
    """
    Preload cache with frequently accessed data.
…