A customer has added response cache policy on all their search APIs, but traffic to the backend has not reduced much. They ask you to investigate…

The scenario describes high cache misses despite the caching mechanism functioning correctly. This is a classic symptom of an overly specific or "brittle" cache key. For search APIs, GET requests can contain numerous query parameters, some of which might be volatile or non-essential for defining a unique, cacheable response (e.g., a timestamp, a unique request ID, or case variations in a search term). If these parameters are included as key fragments in the CacheKey configuration, almost every request will generate a unique key, resulting in a cache miss. By reviewing and refining the key fragments to include only the essential parameters that define the search result, the cache hit ratio will improve, and backend traffic will decrease.

A. Use lookup/populate cache policy.

This is incorrect because the ResponseCache policy is essentially a combined implementation of LookupCache and PopulateCache. Switching to the individual policies does not address the root cause of the high cache misses, which is the cache key configuration.

B. Increase the TimeToLive of cached objects.

This is incorrect because the problem is not that cached items are expiring too quickly, but that they are not being reused. If each request has a unique cache key, increasing the TTL will not help because subsequent, similar requests will still miss the cache.

D. Review and increase the number of items on the cache resource to a higher number.

This is incorrect because the issue described is a low cache hit ratio, not cache eviction due to the cache being full. Increasing the cache's capacity will not solve the problem of overly specific cache keys preventing cache hits.

---

1. Official Google Cloud Apigee Documentation

"ResponseCache policy":

Section: element: The documentation states

"The element configures a unique pointer to a piece of data stored in the cache." It further explains that key fragments are used to construct this key. This directly supports the idea that the key's composition is critical for effective caching. The example shows using request.queryparam.w as a key fragment

highlighting that query parameters are a primary source for key construction. The problem described in the question is a direct consequence of poorly chosen key fragments.

Section: "Usage notes": "The cache key size is limited to 2 KB. If your cache key is larger than 2 KB

you will not be able to cache the response." While not the direct issue here

it emphasizes the importance of carefully constructing the key from only necessary components.

2. Official Google Cloud Apigee Documentation

"Add caching to improve performance":

Section: "About the cache key": "The cache key... provides a way to ensure you get a unique key for cached data. The most common cache key is composed of a combination of dynamic values (values extracted from a request

such as a query parameter or an HTTP header) and static values." This reinforces that the choice of dynamic values (query parameters) is the central element in configuring the cache effectively

which is the focus of the correct answer (C).