Caching Strategies

Introduction

The fastest database query is the one you never make. Caching stores copies of computed data in fast, in-memory systems so future requests are answered instantly. However, caching introduces a major challenge: keeping cached data in sync with the source database.

Background

Caching can be applied at three primary levels: 1. **Edge (CDN)**: Caches static files and API responses geographically close to users. 2. **Application (Redis/Memcached)**: Stores database queries, user sessions, and heavy computations in-memory. 3. **Browser**: Uses HTTP headers to tell client browsers to store assets locally.

Implementation

We implemented a Cache-Aside pattern (Lazy Loading) inside our Node.js services. The application checks the Redis cache first. On a cache miss, it reads from the database, saves the result back to Redis with a Time-To-Live (TTL), and returns the response.

Challenges

Managing large caching layers presents several operational difficulties:

• Cache Invalidation: If data changes in the database, the cache remains stale until the TTL expires, leading to inconsistent user states.
• Cache Stampede: Under heavy concurrent load, multiple threads notice a cache miss simultaneously and hit the database at once, causing server crashes.

Solutions

We solved this by establishing robust caching policies:

1. Write-Through invalidation: Database update events trigger cache evictions (redis.del(cacheKey)) instantly.
2. Mutex Locking: Using lightweight Redis-based locks (Redlock) to ensure only a single worker fetches data from the database on a cache miss, while other requests wait.

Results

Integrating Redis reduced database read traffic by 85% during traffic spikes, and p99 response times dropped from 220ms to under 8ms.

Conclusion

Caching is essential for building fast, scalable applications. By combining CDN edge caches, lazy-loading Redis models, and transactional cache evictions, you can build systems that handle millions of requests without overloading databases.