Home > Candidate Patterns > Response Caching

Response Caching


How can the results of previously processed, yet still valid responses be reused by service consumers?


Service consumers required to repeatedly invoke the same service capability and then return response messages that have not changed can impose increased runtime overhead and unnecessarily high response times.


In order to avoid wasteful request and response messaging, response message data is cached in various locations within the technology architecture that underlies service consumers and services.


Service consumers maintain their own cache to avoid repeatedly requesting the same data and improve response latency when the cached data is still fresh. Data centers maintain their own cache to avoid duplicate requests and responses flowing unnecessarily across their network connections. Services maintain their own cache to avoid processing loads associated with repeated requests.

Response messages indicate their "cacheability" using metadata. Implicit caching information is included in contracts for when no explicit information is provided.

Cache components that understand the contract in use can choose to persist the response between requests. These components are able to determine whether two requests are equivalent for caching purposes, or whether they differ.

A cached response is reused when a new request is determined to be equivalent to the earlier request, and the cached response is still fresh. A validation check back to the service may be used to ensure freshness.


The latency, bandwidth, and processing impact of redundant requests is reduced or eliminated. Consumers that issue similar requests may be able to reuse each other's responses, reducing impact on services.

Caches must understand the contract in use and Reusable Contract can be further applied to increase cache effectiveness.

Explicit caching control decisions must be made by services. These decisions may require the service to generate unique identifiers for new versions of its data, or that the service changes its data at a predictable rate. An unambiguous means of determining that a later request is equivalent to an earlier request for caching purposes is required.

Inaccurate caching metadata could lead to stale information being used by service consumers.


Inventory, Composition, Service


Under Review


Raj Balasubramanian, Benjamin Carlyle, Cesare Pautasso

Figure 1 - Caches placed at various locations can reduce latency (by eliminating requests to the service), decrease bandwidth usage (by limiting requests sent across network links), and lessen processing effort (by reducing requests sent to core service logic). Caches are particularly useful for decreasing overhead in stateless architectures.

Related Patterns in This Catalog

Content Distribution Network, Lightweight Endpoint, Reusable Contract

Related Service-Oriented Computing Goals

Increased Organizational Agility, Reduced IT Burden