Invalidate App Cache via Pub/Sub

Entity events are published by push both for apps and push campaigns. Consumers use them to invalidate the cache both in-memory (first-level) and Redis (second-level).

Entity events are consumed by client service, DES and inbox service.

Client service and DES share the same Redis app cache: client service removes the app from the Push Redis when handling an entity event and adds the app to Push Redis on demand. DES reads the app keys in Push Redis. That’s a hidden dependency between client service and DES and should be avoided in the new solution.

In RabbitMQ a fanout exchange is used to publish the event to all queues. Each subscriber creates a queue with a unique name and binds it to the exchange.

The same can be done in Pub/Sub: clients use unique subscriptions to the invalidation topic.

Push service publishes to Pub/Sub instead of publishing to RabbitMQ. Just sending app invalidation events is enough since no usage of push campaign entity events was found.

Each subscriber has to create a subscription with a unique name and then can react to the Pub/Sub messages. When the pod terminates, the subscription should be deleted. The Expiration period must be set for the subscription in case when the termination handler does not work correctly.

Delivery service also wants to use cache invalidation of app in the future.

The Redis cache reduces the load to push web. If there is no second-level cache, each pod has to get the app from push to store in the in-memory cache.

Push endpoint /api/internal/applications/:code uses an in-memory cache but without invalidation. Therefore, the cache keys expire after just one minute. The push endpoint gets just ~19 requests/second (data from three days 2025-05-04 to 2025-05-06). I.e. it is not worth having a cache manager which updates the Redis cache and then sends invalidation messages to the pods (like we did in DES).

DES and client service should use a dedicated Redis for the app cache instead of the push/inapp Redis.