Caching

Queuety includes a cache layer that reduces database queries on hot paths like queue pause checks, rate limit counters, workflow state lookups, and lock operations. The cache is initialized automatically when you call Queuety::init().

Cache interface

All cache backends implement Queuety\Contracts\Cache:

Method	Returns	Description
`get( string $key )`	`mixed`	Retrieve a value. Returns `null` if not found or expired.
`set( string $key, mixed $value, int $ttl = 0 )`	`void`	Store a value. TTL of 0 means no expiry.
`delete( string $key )`	`void`	Remove a value.
`has( string $key )`	`bool`	Check if a key exists and is not expired.
`add( string $key, mixed $value, int $ttl = 0 )`	`bool`	Set a value only if the key does not already exist (atomic). Returns `true` if the value was set.
`flush()`	`void`	Remove all items from the cache.

Built-in backends

MemoryCache (default)

Queuety\Cache\MemoryCache is an array-backed, per-process cache. Items are stored in a PHP array and lost when the process exits. This is the default backend when APCu is not available.

No extensions required
Suitable for single-worker deployments
Each worker process has its own isolated cache

ApcuCache

Queuety\Cache\ApcuCache uses the APCu extension for shared memory across all PHP processes on the same server. All keys are automatically prefixed with queuety: to avoid collisions with other applications.

Requires the php-apcu extension
Cache is shared across all workers on the same server
The add() method is truly atomic via apcu_add()

Auto-detection

Queuety\Cache\CacheFactory picks the best available backend automatically:

If apcu_store() exists and apcu_enabled() returns true, use ApcuCache
Otherwise, fall back to MemoryCache

This happens inside Queuety::init(). You do not need to configure anything for the default behavior.

What gets cached

The cache layer is used internally by several subsystems:

Data	Purpose
Queue pause state	Avoids a database query on every worker loop iteration
Rate limit counters	Tracks execution counts in memory instead of the database
Workflow state	Reduces reads during multi-step workflow advancement
Lock state	Speeds up lock existence checks for unique jobs and mutex middleware

TTL configuration

The default cache TTL is 5 seconds. Override it with the QUEUETY_CACHE_TTL constant in your wp-config.php:

define( 'QUEUETY_CACHE_TTL', 10 ); // 10 seconds

A lower TTL means more frequent database queries but fresher data. A higher TTL reduces database load but introduces more staleness. For most deployments, the default of 5 seconds is a good balance.

Custom cache backend

To use a custom cache backend (Redis, Memcached, or anything else), implement the Contracts\Cache interface and call Queuety::set_cache() before Queuety::init():

use Queuety\Contracts\Cache;
use Queuety\Queuety;

class RedisCache implements Cache {
    public function get( string $key ): mixed { /* ... */ }
    public function set( string $key, mixed $value, int $ttl = 0 ): void { /* ... */ }
    public function delete( string $key ): void { /* ... */ }
    public function has( string $key ): bool { /* ... */ }
    public function add( string $key, mixed $value, int $ttl = 0 ): bool { /* ... */ }
    public function flush(): void { /* ... */ }
}

// Set the cache before init() so all subsystems use it.
Queuety::set_cache( new RedisCache() );
Queuety::init( $connection );

If set_cache() is called before init(), the factory auto-detection is skipped entirely and your custom backend is used.

Accessing the cache

Retrieve the active cache instance at any time:

$cache = Queuety::cache();

$cache->set( 'my_key', 'my_value', 60 );
$value = $cache->get( 'my_key' );

This returns whatever backend is currently active (MemoryCache, ApcuCache, or your custom implementation).

On this page