PHP Cache Stampede — Why 500 Requests Killed Our Database

Every PHP app eventually meets the same wall: the database query that snapped at 100 users crawls at 10,000. You can scale horizontally, but that burns money. Caching is the cheap fix — compute once, serve a million times. The catch? Get it wrong and you'll serve stale data or crash the database during a stampede.

Here's the hard truth: caching isn't free. Every cache hit saves time, but every cache miss costs more than a direct computation because of serialisation overhead. That's why your cache hit ratio matters more than the cache type you pick.

By the end of this article you'll know exactly when to use APCu, Redis, file cache, or HTTP headers. You'll understand TTL design, stampede prevention, invalidation patterns, and the production mistakes that silently corrupt data. Real, runnable code accompanies every concept.

What Is Caching in PHP? — The Core Problem and How to Fix It

Caching in PHP isn't about storing everything — it's about identifying the expensive operations your app repeats. Think: the same database query returning identical results, an API call that hasn't changed, or a heavyweight HTML snippet. Caching stores that result once and serves it directly for subsequent requests.

Here's what no one tells you: a cache miss costs more than a direct computation because of serialisation overhead. If your hit ratio drops below 90%, caching may actually hurt performance. That's why you must monitor it — not just set it and forget it.

A typical example: a product list query that takes 200ms. If you cache it for 60 seconds and serve 1000 requests per minute, you save 200ms × 999 = ~200 seconds of DB time per minute. That's the ROI. But get the TTL wrong and the stampede will burn you.

<?php

namespace TheCodeForge\Caching;

class ApplicationCache
{
    private int $warmupCount = 0;

    public function get(string $key, callable $expensiveCall, int $ttl = 3600): mixed
    {
        $cached = apcu_fetch($key, $hit);
        if ($hit) {
            return $cached;
        }
        $this->warmupCount++;
        $value = $expensiveCall();
        apcu_store($key, $value, $ttl);
        return $value;
    }

    public function warmups(): int
    {
        return $this->warmupCount;
    }
}

APCu: In-Process Cache for Microsecond Reads

APCu (APC User Cache) stores key-value pairs in shared memory available to all PHP-FPM workers on the same machine. It's the fastest cache you can get because there's no network I/O — reads take 100–300 nanoseconds. Perfect for computed data that is cheap to recompute and shared across requests on a single server.

But APCu's speed is also its biggest limitation: it only lives on one server. If you have multiple web servers, each has its own copy, and cache invalidation becomes a coordination problem. You also burn RAM per server — a 1 GB APCu store consumes 1 GB of memory on every node.

Here's a typical pattern: caching an expensive database query result that changes rarely. APCu fragmentation silently increases memory usage — monitor it via apcu_sma_info() in production and restart PHP-FPM when fragmentation exceeds 20%.

<?php

namespace TheCodeForge\Caching;

class ApcuProductLookup
{
    private int $ttlSeconds;

    public function __construct(int $ttlSeconds = 300)
    {
        $this->ttlSeconds = $ttlSeconds;
    }

    public function getProductData(int $productId): array
    {
        $key = 'product:' . $productId;
        $cached = apcu_fetch($key, $hit);

        if ($hit) {
            return $cached;
        }

        // Cache miss: fetch from database
        $data = $this->loadFromDatabase($productId);
        apcu_store($key, $data, $this->ttlSeconds);
        return $data;
    }

    private function loadFromDatabase(int $productId): array
    {
        // Simulated heavy query
        usleep(50_000); // 50ms
        return ['id' => $productId, 'name' => 'Widget', 'price' => 9.99];
    }
}

Redis: Shared Distributed Cache for Multi-Server Apps

Redis is an in-memory data store accessed over TCP. In PHP, you'll typically use the PhpRedis extension or the predis/predis library. Redis gives you a single cache that every PHP worker — no matter which server — can read from and write to. This makes cache invalidation straightforward: delete the key and every server sees the change instantly.

The trade-off is network latency: each cache operation adds ~0.2–1ms round-trip. At 10,000 requests per second, that's 10 seconds of network overhead. But that's still orders of magnitude faster than querying a database.

A common pattern: cache an API response to avoid hitting rate limits or third-party latency. Redis connections are persistent — always reuse the same connection across requests. Opening a new connection per request adds ~5ms overhead, which destroys the benefit.

Monitoring tip: track keyspace_hits and keyspace_misses in Redis info. A hit ratio below 80% means your cache is mostly wasting memory.

<?php

namespace TheCodeForge\Caching;

use Redis;

class RedisWeatherService
{
    private Redis $redis;
    private int $ttlSeconds;

    public function __construct(string $host = '127.0.0.1', int $port = 6379, int $ttlSeconds = 600)
    {
        $this->redis = new Redis();
        $this->redis->connect($host, $port);
        $this->ttlSeconds = $ttlSeconds;
    }

    public function getTemperature(string $city): ?float
    {
        $key = 'weather:' . $city;
        $cached = $this->redis->get($key);

        if ($cached !== false) {
            return (float) $cached;
        }

        // Simulated external API call
        $temp = $this->fetchFromApi($city);
        $this->redis->setex($key, $this->ttlSeconds, $temp);
        return $temp;
    }

    private function fetchFromApi(string $city): float
    {
        usleep(200_000); // 200ms
        return 22.5;
    }
}

File Cache: Simple, No Dependencies, but Watch the I/O

Sometimes you can't install extensions or run a separate service. A file-based cache writes serialised data to disk. It's trivial to implement — file_put_contents to write, file_get_contents to read, plus a timestamp check for TTL. This works great for small deployments, shared hosting, or as a fallback when Redis is unavailable.

The catch: file I/O is orders of magnitude slower than memory. At high concurrency, multiple processes writing to the same file create corruption risks. And there's no built-in eviction — your storage grows unbounded unless you clean it up.

Here's a safe implementation with proper locking and TTL. Under high concurrency, file locks cause contention — measure with iostat or lsof. If you see high wait time, switch to memory-based cache immediately.

Pro tip: for low-traffic sites (<10 req/s), file cache is perfectly fine. For anything above 100 req/s, you need memory.

<?php

namespace TheCodeForge\Caching;

class FileCache
{
    private string $cacheDir;

    public function __construct(string $cacheDir)
    {
        $this->cacheDir = rtrim($cacheDir, '/');
        if (!is_dir($this->cacheDir)) {
            mkdir($this->cacheDir, 0775, true);
        }
    }

    private function path(string $key): string
    {
        // Sanitise: only alphanumeric and dash
        return $this->cacheDir . '/' . preg_replace('/[^a-zA-Z0-9\-]/', '_', $key) . '.cache';
    }

    public function get(string $key, int $ttlSeconds = 0): mixed
    {
        $file = $this->path($key);
        if (!file_exists($file)) return null;

        $expires = filemtime($file) + $ttlSeconds;
        if ($ttlSeconds > 0 && time() > $expires) {
            unlink($file);
            return null;
        }

        $data = file_get_contents($file);
        return unserialize($data);
    }

    public function set(string $key, mixed $value): void
    {
        $fp = fopen($this->path($key), 'c+');
        flock($fp, LOCK_EX);
        fwrite($fp, serialize($value));
        fflush($fp);
        flock($fp, LOCK_UN);
        fclose($fp);
    }
}

HTTP Cache: Use Browser and Edge to Eliminate Requests Entirely

HTTP caching works by telling the browser (or a reverse proxy like Varnish or CloudFlare) how long it can reuse a response without asking your PHP server at all. This isn't just fast — it eliminates the PHP execution entirely for cached resources. For public, static-like content (images, CSS, API responses that don't change per user), HTTP caching is the highest-leverage optimisation.

Two key headers: Cache-Control: max-age=3600 tells the browser to cache for 1 hour. ETag provides an opaque hash — the browser sends If-None-Match on subsequent requests, and you return 304 Not Modified without sending the body.

Important nuance: HTTP caching doesn't happen inside PHP. It's a contract between your server and the client. You must ensure your PHP correctly sets headers and respects If-Modified-Since or If-None-Match. For global audiences, use a CDN with revalidation — stale content gets cleared from the edge within minutes when you invalidate via the CDN API.

<?php

namespace TheCodeForge\Caching;

class HttpCacheHandler
{
    public function handleRequest(): void
    {
        $etag = '"product-list-v3"';
        header('Cache-Control: public, max-age=3600');
        header('ETag: ' . $etag);

        if (isset($_SERVER['HTTP_IF_NONE_MATCH']) && $_SERVER['HTTP_IF_NONE_MATCH'] === $etag) {
            http_response_code(304);
            exit;
        }

        // ... generate full response ...
    }
}

Cache Invalidation: The Hardest Problem in Computer Science

‘There are only two hard things in computer science: cache invalidation and naming things.’ — Phil Karlton. Cache invalidation is about ensuring that when the underlying data changes, the cached version is either removed or updated. Without it, users see stale data. Over-invalidation trashes your cache hit ratio and kills performance.

In practice, most applications use a combination: a short TTL as a safety net, plus explicit invalidation on writes. Cache poisoning happens when an attacker controls the cache key (e.g., SQL injection in the key). Always sanitise cache keys.

<?php

namespace TheCodeForge\Caching;

class ProductInvalidator
{
    public function __construct(
        private Redis $redis,
    ) {}

    public function onProductUpdate(int $productId): void
    {
        // Delete multiple cache keys
        $keys = [
            'product:' . $productId,
            'product_list:category:' . $this->getCategory($productId),
            'home_page:featured'
        ];

        foreach ($keys as $key) {
            $this->redis->del($key);
        }

        // Optionally notify other layers via pub/sub
        $this->redis->publish('cache:invalidate', json_encode([
            'type' => 'product',
            'id' => $productId,
            'timestamp' => time()
        ]));
    }

    private function getCategory(int $productId): int { /* implementation */ }
}

Cache Monitoring and Observability in Production

You can't fix what you don't measure. Cache monitoring is often an afterthought — teams add caching, see a performance boost, then never look again until something breaks. The two numbers that matter: hit ratio and eviction rate.

For APCu, use apcu_cache_info(true) to see hits, misses, and memory usage. For Redis, INFO stats gives keyspace_hits and keyspace_misses. For file cache, track disk usage and file age.

Set up alerts: when hit ratio drops below 90% for more than 5 minutes, something changed — a deployment, a growth spike, or a bug in key naming. Missing keys silently degrade performance. Also monitor evictions; a sudden increase means your cache size is too small.

Real example: a team used Redis with a 256 MB limit. Traffic grew, evictions jumped, hit ratio dropped to 50%. The app slowed to a crawl. They increased maxmemory to 2 GB and added monitoring — problem solved before the next spike.

<?php

namespace TheCodeForge\Caching;

class CacheMonitor
{
    public static function report(): array
    {
        $data = [];
        if (function_exists('apcu_cache_info')) {
            $info = apcu_cache_info(true);
            $data['apcu_hits'] = $info['num_hits'];
            $data['apcu_misses'] = $info['num_misses'];
            $data['apcu_hit_ratio'] = $info['num_hits'] / max($info['num_hits'] + $info['num_misses'], 1);
        }

        // For Redis, parse INFO stats
        // $redis->info();

        return $data;
    }
}

OpCache: The Free Cache You're Already Running Wrong

Most devs treat OpCache as a set-it-and-forget-it checkbox. That's a production fire waiting to happen. OpCache stores precompiled PHP bytecode in shared memory, skipping the parse/compile phase on every request. PHP 8.x makes this even faster with JIT compilation, but only if you configure it for your actual workload. The default settings are optimized for shared hosting, not for your app. The whocares: validation timestamps are off by default. That means if you deploy new code via FTP (don't) or a symlink swap, OpCache serves stale bytecode until you restart PHP-FPM or call opcache_reset(). Set opcache.validate_timestamps=1 in production, or use a deployment script that invalidates the cache. OpCache is always the first caching layer because it's free, already installed, and reduces response time by 10-30ms.

// io.thecodeforge
[opcache]
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=2
opcache.validate_timestamps=1
opcache.fast_shutdown=1
opcache.jit=tracing
opcache.jit_buffer_size=128M

Cache Stampede Protection: Don't Let a Miss Kill Your DB

A cache stampede is when 100 requests all miss at once, and they all hit the database. It's not a theory — it's the reason your pager went off at 3 AM. The fix is simple: use a mutex or probabilistic early expiration. PHP 8.x gives you fiber-based concurrency, but for cache stampedes, you want a distributed lock via Redis or APCu. The pattern: when a cache miss happens, try to acquire a lock. Only the first request rebuilds the cache; the rest wait or serve stale data. Redis SET NX + EXPIRE is the standard. APCu can also serve as a single-server lock. Another approach: set the TTL to 2x the expected rebuild time, and randomly expire earlier. This spreads out the refresh load. Don't use file-based mutexes on NFS — they're not atomic. Test your stampede handling with a chaos monkey script that flushes your cache in production during peak load.

// io.thecodeforge
function getExpensiveData(Redis $redis, string $key, callable $loader, int $ttl = 300): mixed {
    $cached = $redis->get($key);
    if ($cached !== false) {
        return json_decode($cached, true);
    }

    // Attempt to acquire lock for 10 seconds
    $lockKey = $key . ':lock';
    $lock = $redis->set($lockKey, 1, ['nx', 'ex' => 10]);

    if ($lock) {
        try {
            $data = $loader();
            $redis->setex($key, $ttl, json_encode($data));
            return $data;
        } finally {
            $redis->del($lockKey);
        }
    }

    // Wait and retry
    usleep(100_000); // 100ms
    $cached = $redis->get($key);
    if ($cached !== false) {
        return json_decode($cached, true);
    }

    // Fallback: let this thread be the loader if lock expired
    return getExpensiveData($redis, $key, $loader, $ttl);
}