Cached data repurposing

#Conventional data caches provide a fast way to access data. One typical type of cache uses a hash function related to a request for data to determine a cache location corresponding to the requested data, which facilitates constant time lookup. If the requested data is found in the cache, the data is returned from the cache. If not, (that is, there is a cache miss), the data is retrieved from another source (e.g., a physical data store), returned in response to the request and written into the cache at the appropriate location.

#Each data entry in the cache is typically associated with an expiration value, such as a time-to-live or timestamp value. When a request for cached data is received but the data is determined to be expired, the expired data is typically treated as a cache miss, resulting in returning the data from the other source and updating the cache entry with the non-expired data and a new expiration value. At times there are problems with obtaining the data from the other source, however.

#This Summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter.

#The technology described herein is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:

#FIG. 1 is a block diagram representing example components that handle requests for data including via caches with possibly expired data, according to one or more example implementations.

#FIG. 2 is a block diagram representing example components of a front-end request handling server that may return repurposed (expired) data in a response to a request when no unexpired data is available, according to one or more example implementations.

#Various aspects of the technology described herein are generally directed towards reusing data that is expired when no fresher data is obtainable. In general, the technology operates to avoid returning an error in response to a client request when possible. To this end, one or more aspects are directed towards returning stale data in response to a request rather than an error, such as when an attempt to obtain fresher data fails or is taking an undesirable amount of time. As used herein, requested data is not “available” when a request seeking that data times out (which may or may not be an actual error) and/or fails because of any other error.

#In one or more aspects, stale data is not discarded but returned to a requesting entity, typically along with some indication that the data is stale. This may be a conventional timestamp or time-to-live (TTL) value already associated with the cached data, or some other flag. The requesting entity may then attempt to obtain the data from another source, such as another service, physical database or the like. If this attempt fails or takes too long, the requesting entity may return the stale data to the client in response to the original request. As can be readily appreciated, this provides for satisfying client requests in scenarios where stale data is acceptable to an extent, rather than returning errors or taking so long that the client user gets frustrated.

#By way of example, consider a client device that is requesting a user's watch-list, comprising a set of items representing television content that the user has specifically identified as desirable for viewing. Items on a watch-list expire, such as when a show on that watch-list is no longer offered to be viewed (e.g., a show may only be offered for viewing for a limited period of time). It is also feasible that a show may be automatically added to a user's watch-list. In the event that the new watch-list cannot be built from a data service servers/databases, such as when a database is down, an expired watch-list from a cache may be returned to the user. Although this watch-list may not accurately reflect what is currently viewable, it is likely preferable to the user to view a somewhat outdated watch-list than to instead receive an error message when requesting his or her watch-list; often, the user may not notice.