Implement caching using Spring Caching and Caffeine for local and Redis for distributed (SZ-5)
rk@tigase.net opened 3 weeks ago

Implement Caching with Spring Caching (Caffeine + Redis)

Goal:
Introduce caching to improve performance and reduce database load. Use Caffeine for local development and Redis for distributed environments.

Estimated Time: 4–6 hours


Task Breakdown

1. Add Spring Caching Support

  •  Add spring-boot-starter-cache to pom.xml
  •  Enable caching via @EnableCaching in the config class

2. Configure Local Caffeine Cache

  •  Add Caffeine dependency
  •  Configure cache spec via application.yml
  •  Test cache hit/miss behavior for selected methods

3. Configure Redis for Distributed Caching

  •  Add Redis dependencies (spring-boot-starter-data-redis)
  •  Use profile-based configuration to switch between local and Redis
  •  Configure Redis connection via application-prod.yml or env

4. Apply Caching to Key Methods

  •  Annotate service-layer methods with @Cacheable, @CacheEvict
    • Example: getUserById, getProjectById, searchIssues
  •  Define sensible cache names and TTLs
  •  Add conditional caching if needed

5. Validate Caching Behavior

  •  Write integration tests to verify caching
    • Check initial call vs repeat call
  •  Confirm that Redis keys are being stored correctly (when in prod profile)

🕒 Estimated Time: 4–6 hours

Subtask Estimates

TaskEstimated Time
Add and configure Spring Cache + Caffeine~1.5 hours
Redis integration and profile switch~1.5 hours
Apply annotations and optimize cache usage~1 hour
Test and validate cache behavior (local + Redis)~1 hour

Output Artifacts

  • Local cache: Caffeine via @Cacheable
  • Prod cache: Redis via profile-based config
  • Configurable TTLs and cache regions
  • Verified caching behavior in integration tests
  • Andrzej Wójcik (Tigase) commented 2 weeks ago

    @kobit @rk I understand that we would like to "optimize" the app using caching, but I wonder if usage of Redis at the start is a good idea? If we would like to have a product for Tygrys then we need to think about memory usage on the cluster. As far as I know Redis is not memory hungry, but still that is another thing to deploy and maintain. Also, I would suggest to look at licensing of Redis, if it would work for us: https://redis.io/legal/licenses/ - there was a big change in licensing and terms some time ago.

  • rk@tigase.net commented 2 weeks ago

    Great points all around, and I agree that we should be deliberate about any infra we introduce, especially when it comes to memory usage and license constraints.

    For the MVP, I am planning to use Caffeine only — it’s fast, in-process, has zero external dependencies, and works well for our current (single-node) setup. So no Redis or other distributed cache is being introduced at this stage.

    That said, I do want to note that Redis performs extremely well in distributed scenarios and is widely used for caching. But I fully agree it’s worth being cautious — particularly given the Redis Source Available License (RSAL) and the added operational footprint.

    If we ever hit the limits of Caffeine and need a shared cache (e.g., due to multi-node deployments), we have other OSS-friendly alternatives:

    • Memcached (BSD, ultra-lightweight)
    • Hazelcast (Apache 2.0 core, embeddable or remote)
    • Ehcache (Apache 2.0, disk overflow support)
  • rk@tigase.net commented 2 weeks ago

    Optional: Pluggable Cache Past MVP, to keep things flexible, we could even go one step further and define a pluggable CacheManager bean wired to Spring profiles (caffeine, redis, hazelcast, etc.) — so switching providers later is low-friction, as shown below:

    Screenshot 2025-10-10 at 12.37.01 PM.pngScreenshot 2025-10-10 at 12.37.01 PM

  • Andrzej Wójcik (Tigase) commented 2 weeks ago

    @rk I was not against caching or using Redis. I've used it in my own project with SpringBoot successfully. In clustered solution it is used ie. to have shared in-memory storage of HTTP sessions. Switching profiles is also rather easy - occasionally I had to adjust serializers for some classes but nothing really problematic or time consuming.

    My intention was to point that we want to reduce dependencies (especially on external "applications"). In Tygrys we relied on (tried) Mailu, then on Apache James and 1dev. Now Mailu was replaced by James and 1dev is going to be replaced possibly by Sztab. If we introduce additional "dependencies on external applications" we, sooner or later, may end up needing to replace them. Also we need to maintain them (deploy them end upgrade) in Tygrys on possibly many clusters.

  • rk@tigase.net referenced from other issue 2 weeks ago
  • Wojciech Kapcia (Tigase) commented 2 weeks ago

    sidenote:

    That said, I do want to note that Redis performs extremely well in distributed scenarios and is widely used for caching. But I fully agree it’s worth being cautious — particularly given the Redis Source Available License (RSAL) and the added operational footprint.

    AFAIR Redis was forked due to licence change: https://github.com/valkey-io/valkey

issue 1 of 1
Type
New Feature
Priority
Normal
Assignee
Version
none
Sprints
n/a
Customer
n/a
Issue Votes (0)
Watchers (4)
Reference
SZ-5
Please wait...
Page is in error, reload to recover