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:
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.