Do I need to evict redis cache manually in multi-server environment?

[dmitry-naumovich]

Hi, thanks for the starter :)
I'm using bucket4j and your starter to set up rate limits for several endpoints in my Spring boot application which is deployed to the server in production with several instances so I'm using Redis as the storage. My question is, do I need to manually evict the cache periodically? There are many requests coming to the server so if it's not evicted, it would probably be filled up very soon.

I use currencyRateCache with @Cacheable annotation so I'm using @CacheEvict for this cache. But do I really need evicting for apiRequestsThrottlingCache as well?

Here's my Redis Configuration:

public class RedisConfig {

   public static final List<String> CACHE_NAMES = Arrays.asList(
            "apiRequestsThrottlingCache",
            "currencyRateCache");

    @Bean
    public CacheManager cacheManager(RedisConnectionFactory connectionFactory) {
        return RedisCacheManager.RedisCacheManagerBuilder
                .fromConnectionFactory(connectionFactory)
                .initialCacheNames(new HashSet<>(CACHE_NAMES))
                .build();
    }

    @Bean
    public RedisCacheConfiguration cacheConfiguration() {
        return RedisCacheConfiguration.defaultCacheConfig()
                .entryTtl(Duration.ofDays(1))
                .serializeKeysWith(fromSerializer(new Jackson2JsonRedisSerializer<>(String.class)))
                .serializeValuesWith(fromSerializer(new GenericJackson2JsonRedisSerializer()));
    }

    @CacheEvict(allEntries = true, cacheNames = "currencyRateCache")
    @Scheduled(fixedDelay = 60 * 1000)
    public void cashbackProgramsCacheEvict() { }

    @CacheEvict(allEntries = true, cacheNames = "apiRequestsThrottlingCache")
    @Scheduled(fixedDelay = 60 * 60 * 1000)
    public void apiRequestsThrottlingCacheEvict() { }
}

Here's my bucket4j configuration:

bucket4j:
  filters:
    - cache-name: apiRequestsThrottlingCache
      url: /api/first.*
      rate-limits:
        - bandwidths:
            - capacity: 10
              time: 1
              unit: seconds
            - capacity: 500
              time: 1
              unit: minutes
    - cache-name: apiRequestsThrottlingCache
      url: /api/second.*
      rate-limits:
        - bandwidths:
            - capacity: 10
              time: 1
              unit: seconds
            - capacity: 500
              time: 1
              unit: minutes
    - cache-name: apiRequestsThrottlingCache
      url: /api/third.*
      rate-limits:
        - bandwidths:
            - capacity: 20
              time: 1
              unit: seconds
            - capacity: 1000
              time: 1
              unit: minutes
    - cache-name: apiRequestsThrottlingCache
      url: /api/v1/fourth.*
      rate-limits:
        - bandwidths:
            - capacity: 10
              time: 1
              unit: seconds
            - capacity: 500
              time: 1
              unit: minutes

I'm limited to Java 8 and Spring Boot 2.6.1 so I'm using bucket4j-spring-boot-starter of version 0.6.1 and bucket4j-core with bucket4j-redis of version 7.6.0.

[vladimir-bukhtoyarov]

@MarcGiffing @ttulka hello guys,

A few month ago, I implemented smart TTL calculation for Redis entries, so it is not nessesary(in case of redis) to specify global TTL.
Each bucket is able to estimate how long time it is required to refill tokens up to maximum and set this time as TTL, so we do not have anymore to choose global TTL for each bucket. You can read more there https://github.com/bucket4j/bucket4j/blob/155f5d8d823e6ec677bbb7f4fda677ecffa0e237/bucket4j-core/src/main/java/io/github/bucket4j/distributed/ExpirationAfterWriteStrategy.java#L87 and there https://github.com/bucket4j/bucket4j/blob/155f5d8d823e6ec677bbb7f4fda677ecffa0e237/bucket4j-redis/src/main/java/io/github/bucket4j/redis/lettuce/cas/LettuceBasedProxyManager.java#L202

If I understand correctly you don't use built-in to Bucket4j integrations for Redis and implemented own instead, so you can adopt my code into your integration in order to free your clients from specifiyng TTL.