Service caching (Overview tab of a service: "Cache results" with a cache lifetime) is evaluated per service invocation, wherever the service is called from - top level or nested. So:
- A nested service with caching enabled is served from its cache when the outer service calls it with the same inputs, even if the outer service is not cached.
- A cached top-level service returns its cached result including whatever its nested services produced at the time - the nested services are not called at all on a cache hit.
- The cache key is the service + its input values (serialised); different inputs = different entries. The cache is per server (JVM), not shared across cluster members, and is cleared by a restart or by changing the service (new snapshot).
Clearing the cache without a restart: install a new snapshot of the app (every cached service of the old snapshot is dropped), or toggle the service's cache setting in a new snapshot; there is no REST or JavaScript call that flushes a single service cache.
Rules of thumb: cache only read services with a small input domain (reference data, lookups) and never services whose output depends on the user, the time, or data that other steps change during the process; set a lifetime that matches how stale the data may be; remember that caching applies to General System Services / service flows, not to human services or BPD activities.
References