Caching Considerations for Micro Service Architecture

Introduction

Caching is a high-speed data storage process, which stores a subset of data, typically transient in nature, so that future requests for that data are served up faster than by accessing the data’s primary storage location. It aids better product performance with the same resources. Caching works on the locality principle; when any requested data is likely to be requested again, this data is stored closer to the requester, to save time and resources while being fetched the next time. Caching can also aid in fault tolerance. Although caching invalidation is mentioned as a challenging aspect in Martin Fowler’s blog post as one of the TwoHardThings, the other aspects of caching are easier to address.

Cache Implementation Strategies

Cache implementation enhances and aids in a performance gain, whether it is a new project with caching or an existing project that needs to be cached. The following list provides some important cache implementation strategies to explore:

Implementation on Per-Query Basis

In this strategy, when a query is made to the database, the cache is checked for the same query keys and if found, the response from cache is used. If not found, a query is made to the database and the results along with query keys are persisted in the cache.

The disadvantage of this strategy involves modifications in the code (caching code not reusable) and high chance of regressing a working code.

Overriding the Middleware Driver

Some middlewares provide the option to override the default driver behaviour; for example the Mongoose Driver with prototype property in the Query object. In such a case, an additional logic can be appended to check if the cached response exists and can be added prior to sending the query to the MongoDB.

The advantage of this strategy is its ability to centrally handle the caching behaviour of the project without requiring much modifications in an existing code (therefore less chances of regressing a working code).

Replica Store of Responses for Remote API calls

If caching is required to reduce traffic to a remote API to fetch some data (for example, rate limit on Salesforce API calls), then it can be implemented by storing a replica of the API responses record in a local database. Such a record should be persisted along with an expiry time.

When a call is made to a remote API, the local database can be queried first for any record for API query keys. If no records are present locally or for the expired record, the remote APIs can be queried and the response stored in the database with a new expiry time. Also, this caching strategy can aid in fault tolerance as well for the cases when remote APIs are unavailable.

Caching for Micro-Service Architecture -Considerations

It is imperative to understand the following considerations while selecting either a type or a cache configuration:

Cache invalidation strategies

Global cache vs. distributed cache

There is a possibility of a cache-miss scenario in a local cache with each node, due to random distribution of a request across nodes. Hence, the Global Cache is preferred.

Cache eviction policy

Summary

• If caching is required for a limited set of database queries, then the Per Query Modification approach is suitable. Pros: Aids quick implementation for limited scope.
• If caching is required for database queries for the entire project, then the Overriding Middleware approach is suitable. Pros: Efficient code management.
• If caching/fault tolerance is required for remote APIs, then Replica Store of APIs Response can be created. Pros: Easy implementation and effective fault tolerance.