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 very 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 cached value is used as long as none of the values defined in Service Settings have changed. The decision service invokes the service and caches the service response under a new key when a value in the service request changes, such as when there’s a new parameter in the request body, or an attribute value is resolving differently.

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 just for services. If you are not 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 are not 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 attempts to load the first-level cache entry, and if the entry cannot be found, an attempt is made 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. For a service without caching enabled, you’ll see the following message:

For a service with caching enabled, you’ll see the following message: