WordPress Performance: Bloom Filters for REST API Routing

When you’re managing a multi-service WordPress architecture, the biggest bottleneck is often checking if a requested resource exists on a remote microservice before attempting to fetch it. Last month, I was debugging a latency issue where our REST API was hitting a secondary database roughly 400 times per request just to verify user permissions. We were drowning in I/O wait times.

To fix this, we moved toward using Bloom filters as a high-speed, memory-resident interceptor. Instead of querying the remote database, our plugin now checks a local probabilistic data structure. If it says "definitely not here," we skip the remote call entirely.

Understanding the Interceptor Pattern

In a standard WordPress setup, you’d typically reach for rest_pre_dispatch to handle request routing. This filter allows you to hijack the request before the actual controller logic fires.

The goal here is to use probabilistic data structures to make a sub-millisecond decision. Since a Bloom filter might return a false positive (claiming a key exists when it doesn't), it’s perfect for a cache-aside pattern where the "miss" is just a slightly slower database query, but the "hit" is a massive win for WordPress performance.

Here is how we set up the interceptor:

PHP
add_filter( 'rest_pre_dispatch', function( $result, $server, $request ) {
    $route = $request->get_route();
    
    #6A9955">// Only intercept specific endpoints
    if ( strpos( $route, '/my-plugin/v1/remote-data' ) !== 0 ) {
        return $result;
    }

    $id = $request->get_param( 'id' );
    
    #6A9955">// Check our Bloom filter(stored in Redis or local memory)
    if ( ! BloomFilter::contains( 'remote_resources', $id ) ) {
        return new WP_Error( 'not_found', 'Resource does not exist.', [ 'status' => 404 ] );
    }

    return $result;
}, 10, 3 );

Why Bloom Filters Work for WordPress REST API Scaling

We initially tried using a standard wp_cache_get lookup for every ID. It failed because our keyspace was massive—around 2 million active records—and the cache hit rate on the metadata was poor. We were effectively just moving the bottleneck from the database to the object cache.

By implementing WordPress performance: Using Bloom filters for REST API scaling, we shifted the complexity. A Bloom filter with a 1% false-positive rate for 2 million items takes up roughly 2.5MB of RAM. That’s a tiny footprint compared to the overhead of thousands of redundant SQL queries.

Refinement: Dealing with False Positives

You have to accept that these structures are probabilistic. If the filter says "maybe," you must proceed with the actual request. If you're struggling with the math behind this, Bloom filters for efficient membership testing in high-cardinality data covers the trade-offs between space complexity and error rates in detail.

When you're designing your plugin architecture, keep the filter updates asynchronous. We use a background task via Action Scheduler to sync the filter whenever a new resource is created or deleted. Never block the main thread to update the filter; it’ll kill your TTFB.

Frequently Asked Questions

Does this replace my database?

No. It’s an interceptor. It prevents unnecessary queries, but your source of truth must remain the database.

What happens if the Bloom filter is out of sync?

You get a false negative or a false positive. A false positive triggers a remote call that returns a 404—a small performance hit, but not a system failure. A false negative is impossible by design, assuming your hashing algorithm is robust.

Is this overkill for small sites?

Yes. If you aren't hitting thousands of requests per minute, you’re adding maintenance overhead for no real gain. Stick to standard object caching until you actually see a bottleneck in your query logs.

Wrapping Up

Implementing these filters changed how we approach high-scale REST API routing. It’s not a silver bullet, but it’s a sharp tool for specific high-cardinality problems. Next time, I’d probably look into integrating this directly with the wp_cache layer rather than hooking into rest_pre_dispatch manually, as it would make the logic cleaner and more reusable across different endpoints.

If you are dealing with traffic spikes, consider combining this with WordPress REST API Request Throttling: Adaptive Backpressure Patterns to ensure that even when your filters pass, your server doesn't buckle under the pressure.