Today, when notifications-gw receives a REST payload, it validates the bundle, app and event type (BAET) from that payload by calling the notifications-backend internal REST API. The result of that call is cached locally in notifications-gw for 10 minutes using the quarkus-cache extension. If notifications-backend is unavailable for any reasons (e.g. DB maintenance), notifications-gw won't be able to validate the BAET and will reject the incoming REST payload while it could have been forwarded to Kafka.

We should cache remotely the result of the validation call and increase its expiration delay to make notifications-gw more resilient to notifications-backend maintenances/outages. The data should also be manually expired from notifications-backend whenever the BAET is changed from the Notifications Admin UI.

Switching from local to remote caching requires minimal code changes as the quarkus-cache extension supports Redis as a caching provider. See https://quarkus.io/guides/cache-redis-reference for more details.

Acceptance criteria:

• The BAET validation call result is cached remotely in notifications-gw.
• The expiration delay of the BAET validation call result is increased to 1 week.
• The BAET validation call result is manually expired from notifications-backend whenever the bundle, app or event type are updated from the Notifications Admin UI.