Service caching

Caching improves decision evaluation performance and reduces latency by storing data retrieved from services for faster retrieval on subsequent service requests.

A service is a good candidate for caching if service response values don’t change often.

When the decision engine requests information from a service, it caches the service response if the data has not already been cached. On subsequent service requests, instead of invoking the service again, the decision engine uses the cached data until the cache expires.

The cache expires if any of the values defined in Service Settings change, such as a new parameter in the request body or an attribute value that resolves differently. The decision service then invokes the service and caches the service response under a new key.

To prevent changes in request header values from invalidating an HTTP service response cache, you can exclude such headers from the cache key. Learn more in Connecting a service.

PingAuthorize maintains the service response in the cache for the period of time that you define in the Time to live setting for a service.

You can configure cache settings for individual services when you add or edit a service in the Trust Framework. Learn more in Connecting a service.

If you’ve already set up external attribute caching in PingAuthorize and enable caching for a service:

You cannot configure external caching for services only. If you aren’t seeing cache hits in the external cache instance, this might be because the cache entry is also stored locally. Storing cache entries both locally and externally is unique to services. Attributes configured with external caching aren’t stored locally.

Unlike attribute caching, which uses a one-level approach where cache entries are stored and retrieved from the single configured cache type, service caching uses a two-level approach to improve performance and minimize redundancy. For example, if you configure an external Redis cache, a local cache acts as the first-level cache, and the Redis instance acts as the second-level cache.

When making a call to a service, the decision engine tries to load the first-level cache entry, and if the entry cannot be found, tries to load the second-level cache. If neither attempt succeeds, the decision engine makes a call to the service itself. If the second-level cache entry is unreachable, the first-level cache entry is stored for a maximum of 2 minutes.

You cannot clear the cache manually.

By enabling the file-based Debug Trace logger and inspecting service call messages in PingAuthorize/logs/debug-trace.log, you can determine whether the policy decision point (PDP) retrieved service data from the cache.

Learn more in Service cache logging.