> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flipt.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Caching

> This document describes how to configure Flipt's caching mechanisms.

## Caching

Flipt supports both in-memory cache as well as [Redis](https://redis.io/) 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.

<Warning>
  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.
</Warning>

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](/v1/configuration/overview#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.

<Note>
  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.
</Note>

To tune the expiration and eviction interval of the cache set the following in
your configuration:

```yaml theme={null}
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:

```yaml theme={null}
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:

```yaml theme={null}
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:

```yaml theme={null}
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](https://redis.io/blog/redis-clustering-best-practices-with-keys/) documentation.