Redis Caching in Laravel: Practical Patterns to Speed Up Your App
.jpg)
Adding a cache without a strategy usually just moves the problem — stale data shows up somewhere unexpected, or the cache gets so complicated that debugging it takes longer than the original slow query did. This walks through four patterns that actually earn their place in a Laravel app: query caching, cache tags for clean invalidation, rate limiting, and session storage.
Setup
Point Laravel at Redis in .env:
SESSION_DRIVER=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
Make sure the predis/predis package is installed, or set REDIS_CLIENT=phpredis if you're using the PHP extension instead.
Pattern 1: Query caching with automatic invalidation
Wrap an expensive query with Cache::remember(), and use cache tags so you can invalidate related entries as a group rather than tracking individual keys:
$products= Cache::tags(['products'])->remember(
"products.category.{$categoryId}",
3600,
function() use ($categoryId) {
returnProduct::where('category_id',$categoryId)
->with('reviews')
->get();
}
);
// Later, when a product changes — clear only the tagged entries
Cache::tags(['products'])->flush();
This means updating any product only needs one flush() call, instead of hunting down every cache key that might contain stale product data.
Pattern 2: Model observer invalidation
Tying cache flushes to a model observer means invalidation happens automatically, not something you have to remember to add every time you touch the model elsewhere in the codebase:
useApp\Models\Product;
useIlluminate\Support\Facades\Cache;
classProductObserver
{
public functionsaved(Product$product)
{
Cache::tags(['products'])->flush();
}
public functiondeleted(Product$product)
{
Cache::tags(['products'])->flush();
}
}
Register it in AppServiceProvider::boot() with Product::observe(ProductObserver::class); and every save or delete keeps the cache honest automatically.
Pattern 3: Rate limiting with Redis
Laravel's built-in throttle middleware already uses your configured cache store, so switching to Redis automatically makes rate limiting share state correctly across multiple app servers — something the file or array driver can't do:
Route::get('/products', [ProductController::class, 'index']);
});
// Custom limits per route, e.g. 5 requests per minute for a sensitive endpoint
Route::middleware('throttle:5,1')->post('/password/reset', ...);
Pattern 4: Session storage across multiple servers
Once you're running more than one app server behind a load balancer, file-based sessions break — a user's session might land on a server that never saw their login. Redis session storage fixes this by centralizing session state:
SESSION_DRIVER=redis
SESSION_CONNECTION=default
No code changes needed beyond this — Laravel's session handling automatically routes through Redis once the driver is set, and every app server now reads from the same session store.
Where caching actually goes wrong
The failures I see most often aren't performance failures — they're correctness failures. A cache without a real invalidation trigger tied to the actual data change will eventually serve something stale to a user, and by the time someone notices, it's already eroded trust in the feature. Cache aggressively, but invalidate deliberately — every cache write should have a clear answer to "what event clears this."
Working on a Laravel app that's starting to slow down under real traffic? This is exactly the kind of performance work I do as part of web development engagements.