Caching In MicroServices

Real Time Response 

We are living in an era where an enormous hardware capacity is available at affordable price. With the introduction of mobile apps, user base has increased from just being web or desktop app users. Despite of the user base increase, users expect very quick real time response.
Business and customers would hence expect a better and faster performing applications.
Expecting a real time response is a given aspect and not the differentiator. Response time and performance of the application have become crucial aspects unlike the earlier era.

Would distributed transaction be slower?

One might doubt that since in microservices architecture the transaction is distributed, would it not add to latency and performance issues?
Would the applications not be slower since they have to lot of hops and round trip communication?
These points form a base for the need of caching in microservices.

In general, a user interaction needs data inquiry or submission to fulfill a functionality. Data retrieval, its transmission across layers/micro-services and data accuracy are the crucial factors.

What is Caching?

Caching helps us solve the performance riddle. Cache is a fairly known term in the computer science world.
In computing, a cache is a hardware or software component that stores data so that future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation or a copy of data stored elsewhere. A cache is a temporary storage area to store frequently accessed data.

With this mechanism the data once requested, can be served directly from the cache instead of reaching out to the primary data store. Fetching information from a data store is time consuming and expensive operation.

How MicroService Uses Caching?

A micro-service can cache the required data than calling the primary store or source.
This can be done at an application instance level. There is a challenge here though.

Next logical challenge is, in micro-services the number of instances can dynamically. E.g. an instance can go down or few more instances get added to serve additional load etc. In such scenarios application instances will vanish or would not be in place which would result into a functional failure.

Microservices architecture needs a externalized shared state and cache implementation.
This way multiple micro-service instances can talk to the same state and cache. This would ensure the same source is referred and the data/information is accurate.

Implementing Distributed Caching

The mechanism of an externalized shared state & cache implementation improves the scalability, performance and makes them highly available.
As the round trip communication is saved the performance greatly improves.
Cache can present a customized view of the data to the micro-service fine-tuned for its specific use case. A data model that a service owns, work for and is responsible for can be defined and cached. APIs for the same can be built and micro-service can consume that. Data here can be a business configuration or the application configuration.
This definition can be done using bounded-context concept from domain driven design. This gives micro-service independence and autonomy.
Team can own the data model and service implementation independently.

To enable scaling, micro-services can scale by instantiating multiple instances and at the same time it is essential to scale the state & cache layer as well.

A distributed shared externalized caching layer makes micro-services bounded to the domain context, better performant, on scalable across the stack and highly available.

Key Evaluation For Effective Cache Using

There are several factors which needs to be considered carefully.
What data and what kind of data is cached (Business configurations, application configurations, static product data etc)
Eviction policy i.e. when to invalidate the data in the cache and reload the data from primary source.
Caching technique LRU, Least Frequently Used (LFU), Least Recently Used (LRU), Most Recently Used (MRU) etc.

Here is the comparison of two choices. There are other tools and mechanisms too.

Comparison FactorRedisMemcached
What is it?Redis is a blazing fast in-memory data store that provides sub-millisecond latency to power internet-scale real-time applications.Memcached is a Memcached-compatible in-memory key-value store service that can be used as a cache or a data store.
Sub-millisecond latencyYesYes
Data partitioningYesYes
Advanced data structuresYesNo
Multithreaded architectureNoYes
Snapshots, ReplicationYesNo
Transactions, Pub/SubYesNo
Use casesRedis has growing acceptance as it is catering to many diverse domain use cases.Memcached has acceptance in relatively smaller domains such as Web, Mobile Apps, Gaming & Ad-Tech.

Redis provides fine-grained control over eviction and both lazy and active eviction. When ElastiCache used with Redis it also becomes a very comprehensive package.