Caching with Redis and Files

A product page runs one aggregate query plus three HTTP calls to the inventory service: 400 ms per view, every view. The second visitor pays the same 400 ms as the first. Cache-aside fixes this without changing a single table, and Laravel hands it to you as one method:

$product = Cache::remember(
    "product:{$product->id}:{$locale}",       // key
    now()->addMinutes(10),                    // TTL — never omit it
    fn () => $this->buildProductView($product, $locale)   // only runs on a miss
);

remember() is cache-aside (lazy population): the application checks the cache first; on a miss it computes the value itself and writes it back. The cache store is dumb on purpose — it never fetches, it only holds. That inversion is why cache-aside works with any backend and why it is the pattern Laravel uses everywhere (routes, config, and views are all lazily populated caches).

The alternatives exist because cache-aside has a known weakness — the stampede on a cold key, which Cache Invalidation Strategies handles:

Write-through buys read consistency — a read right after a write is never stale — at the price of making every write do double work. For a read-heavy catalog, cache-aside with a bounded TTL wins; for a counter that must never lose an increment, write-through (or no cache) is honest.

Pick the store per environment, not per fashion:

CACHE_STORE=redis          # .env — config/cache.php defines each store

php artisan cache:table      # migration for the database store
php artisan cache:clear      # nuclear: forget every key in the default store
php artisan config:cache     # separate concept — compiles config to one file

The one thing that matters: a cache key must contain every input that changes the output. product:42 is wrong if the response varies by locale, currency, or logged-in tier — write product:42:en-GB:guest. Miss the variant and one visitor's price gets served to everyone.

Two costs hide behind remember(). Serialization: values are PHP-serialize()d (JSON for Redis with the right options), so caching a 2 MB collection moves the cost from query to network. And the miss path runs synchronously inside the request — a cold cache on a busy morning makes every request pay full price at once, which is exactly the failure mode the next two topics exist to prevent.

One Redis server ended up holding your cache, your sessions, and your queue payloads. That is not an accident of configuration — it is because Redis does three things those workloads need and a file cannot: sub-millisecond reads over the network, atomic operations on a single-threaded event loop, and persistence that survives a restart.

Compare the mechanics rather than the marketing:

file driver    → open() + read() + unserialize() on local disk; per-server copy
APCu           → shared memory inside one PHP-FPM machine; ~1 µs; gone on restart
Redis          → one TCP round trip (~0.2–0.5 ms in the same AZ) to one shared dataset

A file driver stores each key as a file under storage/framework/cache/data. It costs a syscall and a disk read per hit, it cannot do atomic compare-and-set, and — the killer in any deployment with more than one web server — each server has its own copy. web01 invalidates product:42, web02 keeps serving the stale file for the rest of its TTL. APCu avoids the disk but has the same per-server boundary, which is why it is excellent for compiled routes and config and wrong for anything a second machine must observe.

Redis persistence is why sessions and queues live there too. With RDB snapshots or AOF append-only logging enabled, a Redis restart does not log every user out and does not drop queued jobs:

redis-cli ping                                   # PONG
redis-cli info memory | grep -E 'used_memory_human|maxmemory'
redis-cli info persistence | grep -E 'rdb_last_bgsave_status|aof_enabled'
redis-cli ttl "myapp:cache:product:42"           # seconds remaining, -1 = no expiry
redis-cli --scan --pattern 'myapp:cache:*' | head   # KEYS * blocks the server — never use it

Eviction policy is the setting people skip and regret. Under maxmemory 2gb with maxmemory-policy noeviction, Redis refuses writes the moment it fills up — your cache starts returning errors. allkeys-lru quietly evicts the least recently used keys, which is fine for pure cache and catastrophic if it starts evicting session or queue keys. Production setups keep cache and queue data separated:

// config/database.php
'redis' => [
    'client' => env('REDIS_CLIENT', 'phpredis'),
    'cache' => ['url' => env('REDIS_URL'), 'host' => ..., 'database' => env('REDIS_CACHE_DB', 1)],
    'queue' => ['host' => ..., 'database' => env('REDIS_QUEUE_DB', 2)],
    'sessions' => ['host' => ..., 'database' => env('REDIS_SESSION_DB', 3)],
],

Distinct databases (or at minimum distinct key prefixes — CACHE_PREFIX, QUEUE_PREFIX, SESSION_PREFIX) mean php artisan cache:clear can never flush your queue, and an allkeys-lru policy on the cache DB cannot evict a half-processed job.

Because Redis executes one command at a time, compound actions become atomic — the property neither file nor APCu gives you:

// rate limit: INCR is atomic, so 100 concurrent requests cannot exceed the cap
$hits = Cache::increment("rl:login:{$_SERVER['REMOTE_ADDR']}");
if ($hits === 1) Cache::put("rl:login:{$_SERVER['REMOTE_ADDR']}", 1, now()->addMinute());
if ($hits > 100) abort(429);

// cross-server mutex — needs a lock-capable store (redis, database, file, array, memcached)
$lock = Cache::lock('report:monthly', 30);
$lock->block(5, fn () => $this->buildReport());   // waits up to 5s for the lock

Cache::lock() is the primitive the next topic leans on for both stampede protection and scheduled-task overlap guards. If a store cannot lock, those features fail loudly at runtime — which is the interview follow-up: name one capability a file cache cannot give you, and say why it matters.

One more distinction saves confusion in code review: Redis-as-cache and Redis-as-broker use different data structures. Cache entries are plain string keys with a TTL (SET myapp:cache:product:42 ... EX 600); queue payloads are pushed onto lists and popped with blocking reads. Same server, same memory budget, completely different operational expectations — which is exactly why the next chapter separates cache correctness from cache capacity.

Swapping CACHE_STORE from file to redis is a one-line change that silently alters semantics. Before you ship it, know the three things that actually break in production: the cold-start cliff, memory eviction, and keys that outlive their owners.

The cold-start cliff

A cache miss is not free — it costs the full compute path plus the write. Measure the hit rate, or you are tuning blind:

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses'
# hit rate = hits / (hits + misses) — below ~90% on a read-heavy page, the key design is wrong
php artisan cache:clear           # deploys that run this create a guaranteed stampede window

Two habits remove most of the pain. Warm critical keys during deployment instead of clearing everything — prefer versioned keys (product:v42:42) so old entries age out by TTL while new ones are built by a background job. And bound every miss cost: if buildProductView() takes 400 ms, at least make sure the miss path is what a queue job does, not what your p99 does.

TTLs, prefixes, and orphan keys

Cache::put("cart:{$userId}", $items, now()->addHours(2));   // explicit expiry, always
Cache::forever('feature-flags', $flags);                     // deliberate: config-like data

A missing TTL means an entry that lives until someone runs cache:clear — carts, counters, and rate-limit keys accumulate until Redis hits maxmemory. Conversely, a TTL shorter than the data's real validity hands you stale reads. The rule that settles both: set the TTL to the longest staleness you can defend in an incident, then make the key carry every variant input (locale, currency, user tier) so a stale-but-correct value is still correct.

What changes when you switch stores

Two operational details save real outages. First, php artisan cache:clear on Redis deletes keys matching the current CACHE_PREFIX — if you change the prefix (say, per-release), old keys become unreachable garbage and you must purge them manually (redis-cli --scan --pattern 'old-prefix:*' | xargs -r redis-cli del). Second, the array store is per-request: it is perfect in tests (fast, isolated) and useless in production, where it forgets everything between requests.

Keep the cache out of your incident path entirely: alert on hit rate and on used_memory approaching maxmemory, not on individual key misses. When the read layer is healthy, the interesting failures move to the write side — jobs and scheduled work — starting with Scheduling Recurring Tasks. If you have not yet read Dispatching Queued Jobs, notice that the queue tables and this cache share one Redis instance in most deployments: starving one starves the other, which is why they were separated into distinct databases above.

Interview framing: "How do you choose a cache backend?" Answer with the constraints — shared state across servers, atomicity for locks and counters, memory ceiling and eviction policy, and restart durability — then say which constraint eliminated the file driver for you. That is a design answer, not a shopping answer.