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

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)

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

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

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