Notifications currently lacks the ability to cache data remotely and share that data between replicas of its ClowdApps. It's been determined already that remote caching would have the following benefits:

• Lower the DB input/output operations per seconds, which are currently limiting the Kafka processing throughput in case of incoming messages spike (RBAC seeding).
• Increase the service resiliency to maintenances/outages (related to DB in particular).
• Fetch the recipients info (email addresses...) from IT in a more efficient way, which would address the main bottleneck of Notifications - This will be covered in a follow-up epic (RHCLOUD-36095).

From a dev perspective, remote caching will be implemented with the Redis OSS API which is supported by Amazon ElastiCache: https://aws.amazon.com/elasticache/redis/?nc1=h_ls. Notifications will also use Redis as a caching provider with the quarkus-cache extension which is widely used in the codebase already: the https://quarkus.io/guides/cache-redis-reference. The performance/resiliency benefits of introducing Redis far outweight the implementation costs which are very reasonable.

From a QE testing perspective, most changes should already be covered by existing tests and the effort should be reasonable. The cost of talking to Elasticache (or mock it) from IQE tests has not been determined yet.

Acceptance criteria:

• Notifications is able to cache data remotely in AWS ElastiCache through the Redis API in the commercial stage and prod environments.
• The Kafka messages deduplication logic based on a DB query is replaced with a Redis request.
• The existing local caching is replaced with remote caching wherever that makes sense.
• IQE tests cover all remote caching use cases.