​
Caching

Flipt supports both in-memory cache as well as Redis to enable faster reads and evaluations. Enabling caching has been shown to speed up read performance by several orders of magnitude if you are using a relational database.
Enabling in-memory caching when running more than one instance of Flipt isn’t advised as it may lead to unpredictable results. It’s recommended to use Redis instead if you are running more than one instance of Flipt.
Caching works as follows:
  • All flag reads and evaluation requests go through the cache
  • Flag cache entries are purged whenever a write to a flag or its variants occur or the TTL expires
  • Cache entries are purged after the TTL expires only
  • A cache miss will fetch the item from the database and add the item to the cache for the next read
  • A cache hit will simply return the item from the cache, not interacting with the database
See the Cache section for how to configure caching.

​
Expiration/Eviction

You can also configure an optional duration at which items in the cache are marked as expired. For example, if you set the cache TTL to 5m, items that have been in the cache for longer than 5 minutes will be marked as expired, meaning the next read for that item will hit the database. Setting an eviction interval (in-memory cache only) will automatically remove expired items from your cache at a defined period.
The combination of cache expiration and eviction can help lessen the amount of memory your cache uses, as infrequently accessed items will be removed over time.
To tune the expiration and eviction interval of the cache set the following in your configuration: 
cache:
  enabled: true
  backend: memory
  ttl: 5m # items older than 5 minutes will be marked as expired
  memory:
    eviction_interval: 2m # expired items will be evicted from the cache every 2 minutes

​
Redis

​
Key Prefix

When using Redis as your cache backend, you can configure a prefix that will be added to all Redis cache keys. This is useful when:
  • Multiple Flipt instances share the same Redis instance
  • You want to namespace your cache keys to avoid conflicts
  • You need to identify or manage Flipt’s cache keys separately from other applications
To configure a key prefix, set the following in your configuration: 
cache:
  enabled: true
  backend: redis
  redis:
    prefix: "flipt" # all cache keys will be prefixed with "flipt:" Note: this is the default value

​
Clustering Considerations

Flipt supports Redis in both single and cluster modes as of v1.57.0. The default mode is single. To configure Flipt to use Redis in cluster mode, set the following in your configuration: 
cache:
  enabled: true
  backend: redis
  redis:
    url: "{address}:{port}" # the address and port of your Redis cluster
    mode: cluster
Key Hash Slots In Redis Cluster, keys that need to be part of the same operation (like transactions) must be in the same hash slot. Redis uses a CRC16 hash of the key modulo 16384 to determine which slot a key belongs to. However, you can influence this behavior using hash tags. Hash Tags Hash tags are parts of the key name enclosed in curly braces {}. When a key contains a hash tag, Redis will only use the part within the braces to calculate the hash slot. This allows you to ensure related keys are stored in the same slot. For example, if you’re using Redis Cluster with Flipt and need to ensure certain related keys are on the same node, you can configure your key prefix to include a hash tag: 
cache:
  enabled: true
  backend: redis
  redis:
    mode: cluster
    prefix: "{flipt}" # ensures all Flipt cache keys are in the same hash slot
For more information about Redis Cluster and key management, see the Redis Clustering Best Practices With Keys documentation.