How Global Caching Works

The following steps demonstrate how global caching works when an application makes a cache request for a global topic:

1. A client application sends a cache request, to the local Distributed Cache. The cache request includes a topic with a global prefix, for example: LON/fx/gbp/.

2. The local PubSub+ Cache Instance that receives the request checks whether it has any messages with matching topics cached locally. If there are any messages, it returns them to the client.

   Global caching does not support requests with topic wildcards. Wildcard requests are not sent to home Cache Clusters from the local cluster. If an application makes a wildcard request that spans local and global topics, matching local topics may still be returned but global topics are not.

3. If the PubSub+ Cache Instance does not have any matching messages cached locally and the topic matches a global topic prefix, the PubSub+ Cache Instance does the following:

   1. It adds a subscription for the requested topic to the local Cache Cluster.

      The local subscription allows the local Cache Instance to fulfill subsequent client cache requests for that topic. The local subscription saves WAN bandwidth in the likelihood that additional clients are interested in the same topic. Otherwise, each client’s request would be sent to the home Cache Cluster, which could use up bandwidth at times of day when many clients come online and request large numbers of topics from home Cache Clusters.

   2. It sends the request to the configured home Cache Cluster that is caching messages for the topic.

4. The local PubSub+ Cache Instance receives the cached messages from the home Cache Cluster and, because of its locally added subscription, it begins to cache live data messages for that topic locally.

5. The local Distributed Cache returns the cached messages to the API, which are then provided to the client application through the received message callback.