Invalidation and refresh of multi-tier distributed caches
To deliver up-to-date, coherent user data to applications upon request, the disclosed technology includes systems and methods for caching data and metadata after it has been synchronously loaded—for future retrieval with a page load time close to zero milliseconds. To provide this experience, data needs to be stored as locally to a user as possible, in the cache on the local device or in an edge cache located geographically nearby, for use in responding to requests. Applications which maintain caches of API results can be notified of their invalidation, and can detect the invalidation, propagate the invalidation to any further client tiers with the appropriate derivative type mapping, and refresh their cached values so that clients need not synchronously make the API requests again—ensuring that the client has access to the most up-to-date copy of data as inexpensively as possible—in terms of bandwidth and latency.
1. A method, comprising:
maintaining, by one or more processors, a database cache on a client device running a data consuming application that accesses a data source;
receiving, by the one or more processors, an invalidation message that indicates a list of cache keys changed in response to a request received at a shared cache manager from the data consuming application;
requesting, by the one or more processors, changed data from the shared cache manager upon determining that a key in the list of cache keys has a value stored in the database cache based on the invalidation message by replaying at least one API request impacted by the list of cache keys to an edge server; and
repairing, by the one or more processors, the database cache using the changed data received from the shared cache manager.
2. The method of claim 1 , wherein the data source is a cloud database.
3. The method of claim 1 , the receiving further comprising:
accessing a message broker to receive the invalidation message.
4. The method of claim 1 , further comprising:
decompressing the changed data.
5. The method of claim 1 , further comprising:
securing the request to the shared cache manager using transport layer security.
6. The method of claim 1 , wherein the shared cache manager determines that a follow-up request can be entirely satisfied from cache memory.
7. The method of claim 1 , wherein the shared cache manager pre-caches an updated version of data by replaying at least one API call to access the data source.
8. A system, comprising:
a memory; and
at least one processor coupled to the memory and configured to:
maintain a database cache on a client device running a data consuming application that accesses a data source;
receive an invalidation message that indicates a list of cache keys changed in response to a request received at a shared cache manager from the data consuming application;
request changed data from the shared cache manager upon determining that a key in the list of cache keys has a value stored in the database cache based on the invalidation message by replaying at least one API request impacted by the list of cache keys to an edge server; and
receive the changed data and repair the database cache using the changed data.
9. The system of claim 8 , wherein the data source is a cloud database.
10. The system of claim 8 , wherein to receive the invalidation message the at least one processor is further configured to:
access a message broker to receive the invalidation message.
11. The system of claim 8 , the at least one processor further configured to:
decompress the changed data.
12. The system of claim 8 , the at least one processor further configured to:
secure the request to the shared cache manager using transport layer security.
13. The system of claim 8 , wherein the shared cache manager determines that a follow-up request can be entirely satisfied from cache memory.
14. The system of claim 8 , wherein the shared cache manager pre-caches an updated version of data by replaying at least one API call to access the data source.
15. A non-transitory computer-readable device having instructions stored thereon that, when executed by at least one computing device, causes the at least one computing device to perform operations comprising:
maintaining a database cache on a client device running a data consuming application that accesses a data source;
receiving an invalidation message that indicates a list of cache keys changed in response to a request received at a shared cache manager from the data consuming application;
requesting changed data from the shared cache manager upon determining that a key in the list of cache keys has a value stored in the database cache based on the invalidation message by replaying at least one API request impacted by the list of cache keys to an edge server; and
receiving the changed data and repairing the database cache using the changed data.
16. The non-transitory computer-readable device of claim 14 , wherein the data source is a cloud database.
17. The non-transitory computer-readable device of claim 14 , the receiving further comprising:
accessing a message broker to receive the invalidation message.
18. The non-transitory computer-readable device of claim 14 , the operations further comprising:
decompressing the changed data.
19. The non-transitory computer-readable device of claim 14 , the operations further comprising:
securing the request to the shared cache manager using transport layer security.
20. The non-transitory computer-readable device of claim 14 , wherein the shared cache manager determines that a follow-up request can be entirely satisfied from cache memory.