WordPress performance: Preventing Cache Stampedes with Request Coalescing

Last month, I spent about three days debugging a production REST API that kept flatlining whenever our marketing team pushed a notification. We were seeing a classic cache stampede: thousands of concurrent requests hitting the same expired cache key, causing a massive database spike that essentially locked the site.

If you’ve ever watched your CPU usage hit 100% because every single request decided it needed to re-calculate a heavy response at the exact same millisecond, you know the pain. Solving this requires more than just better hardware; it requires request coalescing to ensure that only one process does the heavy lifting while the others wait for the result.

Why Cache Stampedes Kill WordPress Performance

When you use the standard get_transient() or wp_cache_get() pattern, there’s a race condition. If the cache expires, ten concurrent requests will all see false, and all ten will trigger the expensive database query.

In a high-concurrency environment, this is catastrophic. You end up with ten identical, heavy processes competing for the same MySQL locks. While database performance: preventing cache stampedes with request coalescing is a general concern, WordPress makes this trickier because our request lifecycle is usually synchronous and blocking.

The Strategy: Implementing Request Coalescing

We need a way to "lock" the resource creation. I’ve found that using Redis as a mutex is the most reliable way to handle this in a distributed WordPress environment. If you're already using Redis for object caching, this is a low-friction addition.

Step 1: The Locking Mechanism

Instead of just checking the cache, we check for a "lock" key. If the lock exists, the subsequent requests wait (or return a stale value). If not, the process creates the lock and proceeds. I’ve written about distributed locking in WordPress: redis mutex for rest apis before, which covers the atomic operations needed here.

Step 2: Collapsing the Request

Here is a simplified pattern I use in my custom plugin architecture to coalesce REST API responses:

PHP
function get_coalesced_data($key, $callback, $ttl = 300) {
    $data = wp_cache_get($key);
    if ($data !== false) return $data;

    #6A9955">// Use a lock key to ensure only one process runs the callback
    $lock_key = "lock_{$key}";
    if (wp_cache_add($lock_key, '1', '', 10)) {
        #6A9955">// We own the lock
        $data = $callback();
        wp_cache_set($key, $data, '', $ttl);
        wp_cache_delete($lock_key);
        return $data;
    }

    #6A9955">// Wait and retry logic(simplified)
    usleep(50000); #6A9955">// 50ms
    return get_coalesced_data($key, $callback, $ttl);
}

This simple recursive retry effectively collapses the stampede. The first request does the work, and the others back off and wait for the cache to be populated.

Trade-offs and Lessons Learned

My first attempt at this involved a sleep() loop, which was a terrible mistake. It tied up PHP-FPM workers, leading to 504 Gateway Timeouts. I eventually switched to a short-lived cache-based lock with an exponential backoff, which kept the workers free to handle other, lighter tasks.

If you're looking for even deeper optimizations, consider combining this with WordPress performance: database-level request coalescing for rest api to ensure your queries themselves aren't the bottleneck. It's also worth noting that if you have the resources, you should look into WordPress performance: predictive cache warming for rest api scaling to ensure the cache rarely expires in the first place.

FAQ

Q: Does this work if I’m not using Redis? A: You can use the wp_options table as a fallback, but it’s slower and prone to its own database contention. For high-concurrency, an in-memory store like Redis or Memcached is effectively mandatory.

Q: How long should the lock TTL be? A: Keep it as short as possible. It should only represent the time it takes to generate the response (e.g., 2-5 seconds). If the process crashes, you don't want a permanent lock.

Q: Is there a risk of infinite loops? A: Yes, if your recursive retry logic doesn't have a breaker. Always implement a max_retries counter to fail gracefully if the data can't be fetched within a reasonable timeframe.

Final Thoughts

Request coalescing is one of those "hidden" performance wins that separates a fragile API from a robust one. I’m still experimenting with how to handle "stale-while-revalidate" patterns in combination with these locks, as serving slightly stale data is often better than making the user wait for a regeneration.

If I were to do this again, I’d probably move the locking logic into a dedicated middleware layer rather than burying it inside the service classes. It makes testing significantly easier when the locking behavior is decoupled from the business logic.