Redis Caching Strategies for Web Applications

Redis is an in-memory data store, which makes it dramatically faster than querying a disk-based database for the same data — but "just cache everything" is the wrong instinct. Here are the caching strategies that actually hold up in production.

Cache-Aside: The Default Pattern

function getPost($id) {
    $cacheKey = "post:{$id}";
    $cached = Redis::get($cacheKey);

    if ($cached) {
        return json_decode($cached, true);
    }

    $post = DB::table('posts')->find($id);
    Redis::setex($cacheKey, 3600, json_encode($post)); // expire in 1 hour
    return $post;
}

Check the cache first; on a miss, hit the real database and populate the cache for next time. This is the pattern behind Laravel's own Cache::remember() helper.

Cache Invalidation: The Genuinely Hard Part

function updatePost($id, $data) {
    DB::table('posts')->where('id', $id)->update($data);
    Redis::del("post:{$id}"); // invalidate — next read repopulates with fresh data
}

The famous quote "there are only two hard things in computer science: cache invalidation and naming things" exists for a reason — every write path that touches cached data needs a matching invalidation, and it's easy to miss one, leaving stale data served indefinitely.

TTL: Let Time Do Some of the Work

Redis::setex("user:{$id}:profile", 300, $data); // auto-expires in 5 minutes

A reasonable TTL is a safety net against a missed invalidation — worst case, stale data lives for the TTL window, not forever. Data that changes rarely (a product catalog) can have a long TTL; frequently-changing data (a live leaderboard) needs a short one or no cache at all.

Rate Limiting with Redis

function checkRateLimit($userId) {
    $key = "ratelimit:{$userId}";
    $count = Redis::incr($key);
    if ($count === 1) {
        Redis::expire($key, 60); // window resets every 60s
    }
    return $count <= 100; // 100 requests per minute
}

INCR is atomic — safe under concurrent requests from the same user without any separate locking logic.

Sessions and Queues

Beyond application-level caching, Redis is also the standard backing store for Laravel's session driver and queue driver — both benefit from the same speed advantage, and Redis's pub/sub capability makes it a natural fit for real-time features (live notifications, presence indicators) beyond pure caching.

What NOT to Cache

Data that's already fast to fetch (a simple indexed lookup on a small table) gains little from caching but adds real invalidation complexity. Cache the genuinely expensive operations — complex joins, aggregations, external API calls — where the speed difference is actually measurable.