Today, when notifications-gw receives a REST payload authenticated with an X509 certificate, it validates the cert and retrieves the source environment (stage, prod...) 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 cert and will fail at identifying the source environment. The payload will still be 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 X509 cert is changed.

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 X509 cert validation call result is cached remotely in notifications-gw.
• The expiration delay of the X509 cert validation call result is increased to 1 week.
• The X509 cert validation call result is manually expired from notifications-backend whenever the cert is updated from the Notifications internal REST API.