Redis Caching Strategies That Reduced Our Load Times by 70%

The cache-aside pattern is simple and effective:

1. Application checks cache for data
2. If cache hit → return cached data
3. If cache miss → fetch from database
4. Store result in cache with TTL
5. Return data to application

async function getProduct(productId) {
const cacheKey = `product:${productId}`;

// Try cache first
const cached = await redis.get(cacheKey);
if (cached) return JSON.parse(cached);

// Cache miss - fetch from DB
const product = await db.products.findById(productId);

// Store in cache with 1-hour TTL
await redis.setex(cacheKey, 3600, JSON.stringify(product));

return product;
}

This pattern is lazy—data is only cached when requested. Perfect for most use cases.

There are only two hard things in Computer Science: cache invalidation and naming things. Our strategies:

1. TTL-based: Set expiration times based on data volatility
• Product data: 1 hour
• User profiles: 15 minutes
• Analytics: 5 minutes

2. Event-driven: Invalidate on data changes
• When a product is updated, delete cache key
• Use Redis pub/sub for cross-service invalidation

3. Write-through: Update cache immediately on writes
• Good for data that's read immediately after writing
• Increases write latency slightly

For e-commerce, we use event-driven invalidation for product data and TTL-based for analytics.

We use multiple caching layers for maximum performance:

1. Browser Cache (0ms latency)
• Static assets with long cache headers
• API responses with ETags

2. CDN Cache (10–50ms latency)
• Cloudflare for global edge caching
• Cache HTML pages and API responses

3. Application Cache - Redis (1–5ms latency)
• Database query results
• Computed aggregations
• Session data

4. Database Cache (0ms for repeated queries)
• PostgreSQL query cache
• MongoDB WiredTiger cache

Each layer reduces load on the layer below it.

Here's what tiered caching achieved for our clients:

Hertunba (E-commerce):
• Before: 8.2s average page load
• After: 2.4s average page load (70% improvement)
• Redis caching: Product data, collections, menus
• CDN: Static assets, HTML pages

OneCultur (SaaS):
• Before: 3.5s dashboard load
• After: 800ms dashboard load (77% improvement)
• Redis caching: Aggregated analytics, user permissions

Fix234 (Marketplace):
• Before: 2.1s search results
• After: 200ms search results (90% improvement)
• Redis caching: Service catalog, provider availability

1. Caching everything—cache only what's slow or frequently accessed
2. No invalidation strategy—stale data erodes user trust
3. Caching user-specific data with generic keys
4. Ignoring memory limits—Redis is in-memory, set maxmemory policies
5. Not monitoring cache hit rates—aim for >80% hit rate
6. Caching without compression—large objects waste memory
7. Single point of failure—use Redis Sentinel or Cluster for production

You can't optimize what you don't measure. Track:

• Cache hit rate (target: >80%)
• Cache miss latency
• Memory usage over time
• Eviction rate
• Key count growth

We use Redis INFO command and export metrics to Prometheus for dashboard visualization. Set alerts for:
• Hit rate below 70%
• Memory usage above 80%
• Eviction rate spike
• Response time degradation