Skip to main content
Version: next

Caching strategies

Learn about the available caching strategies in Front-Commerce.

Redis

The Redis implementation allows to cache data in a redis server.

It uses node's ioredis package as a redis client. Please refer to the package documentation for all the available options.

Here is a full configuration example:

app/config/caching.js
export default {
strategies: [
{
implementation: "Redis",
supports: "*",
config: {
// See https://www.npmjs.com/package/redis#options-object-properties
host:
process.env.FRONT_COMMERCE_CLOUD_REDIS_HOST || // Front-Commerce Cloud variables
process.env.FRONT_COMMERCE_REDIS_HOST || // default variables
"127.0.0.1", // default value (localhost)
port:
process.env.FRONT_COMMERCE_CLOUD_REDIS_PORT ||
process.env.FRONT_COMMERCE_REDIS_PORT ||
6379,
db:
process.env.FRONT_COMMERCE_CLOUD_REDIS_DB ||
process.env.FRONT_COMMERCE_REDIS_DB ||
0,
// Front-Commerce options
// defaultExpireInSeconds: 82800, // default: 23 hours
// expireJitter: 8280, // in seconds, disabled by default
// invalidationScanIterationSize: 2000, // default: 1000
},
},
],
};

Spreading cache expirations with expireJitter

Since version 3.22

When the cache is fully flushed, most keys are recreated within a short window and share the same TTL, so they all expire at the same instant later on. That synchronized expiration mimics a new flush and sends a traffic spike to the backend (a "cache stampede" / "thundering herd").

To avoid it, you can add a random jitter to each loader's TTL. The effective expiration becomes expire + random(0, expireJitter) seconds: the TTL is only ever lengthened, never shortened. Because loaders are created per request, keys written by different requests get different TTLs, which spreads the expirations over time.

expireJitter is expressed in seconds and is disabled by default (0). Set it to a positive duration to enable jitter for every loader that relies on the default TTL.

You can also override it per data loader. See Using dataloaders in GraphQL loaders.