A quick Introduction to Distributed Caching

Cache?

The cache is simply the storage capacity for data on a system that is reserved for the quicker servicing of future requests.

Why Caching:

Reduce Network calls
Avoid Re-computations
Avoid load on DB
Improve availability of data, by providing continued service even if the backend server is unavailable
Improved data access speeds brought about by locality of data
Smoothing out load peaks (e.g.: by avoiding round-trips between middle-tier and data-tier)

Distributed Caching

The distributed cache is maintained as an external service to application servers (front-end servers)
Typically deployed on a cluster of multiple nodes forming a large logical cache (horizontal scalability)
Managed in a synchronized fashion, making the same cached data remotely available to all application servers (consistent)
Survives application server restarts and deployments
Preserves high availability

Use Cases Of Distributed Caches

Database Caching to reduce DB bottleneck:

The Cache layer in-front of a database saves frequently accessed data in-memory to cut down latency & unnecessary load on it.

Storing User Sessions:

User sessions are stored in the cache to avoid losing the user state in case any of the instances go down.

Cross-Module Communication & Shared Storage:

Saves the shared data which is commonly accessed by all the services. It acts as a backbone for microservice communication.

In-memory Data Stream Processing & Analytics:

Real-time processing (opposed to traditional ways of storing data in batches & then running analytics on it)
E.g.: anomaly detection, fraud monitoring, online gaming real-time stats, real-time recommendations, payment processing, etc.

Distributed Hash Tables

Generally, a Distributed Cache is based on a Distributed Hash Table (DHT) which is similar to hash-table but spread across multiple nodes.
Key-value pairs are stored in a DHT, and any participating node can efficiently retrieve the value associated with a given key
DHT allows a Distributed cache to scale on the fly, by managing the addition, deletion, failure of nodes continually.

(Image source: https://en.wikipedia.org/wiki/Distributed_hash_table)

Distributed Caching Strategies

There are different kinds of caching strategies that serve specific use cases.

Cache Aside
Read-Through
Write-Through
Write-Back
Write-Around

By selecting proper strategy caches can reduce response times, decrease the load on the database, and save costs. The strategy is selected based on the data and data access patterns ( data size, data uniqueness, access frequency, …).

1. Cache Aside Strategy

Cache sits on the side and the application directly talks to both the cache and the DB.
When the user sends a request for particular data: The system first looks for it in the cache & If present it’s simply returned. Else, the data is fetched from the database, the cache is updated & is returned to the user.
Data is lazy loaded into cache.
In this strategy, the data is written directly to the database. This means things between the cache and the database might get inconsistent.
- To avoid this, data on the cache has a TTL (Time to Live). After TTL the data is invalidated from the cache.
Resilient to cache failures. (If the cache cluster goes down, the system can still operate by going directly to the database.)
Best suits for:
- Read-heavy workloads
- Data that is not much frequently updated: e.g.: user profile data (name, birthday, etc.).

2. Read-Through

Cache sits in-line with the database.
When there is a cache miss, it loads missing data from the database, populates the cache and returns it to the application.
The cache always stays consistent with the database.
Best suits for Read-heavy workloads.

3. Write-Through

Data is first written to the cache and then to the database.
The cache sits in-line with the database and writes always go through the cache to the main database.
Maintains high consistency between the cache and the database (but, adds a little latency during the write operations as data is to be updated in the cache additionally.)
Best suits for, write-heavy workloads like online multiplayer games.

4. Write-Back (write-behind)

The application writes data to the cache which acknowledges immediately and after some delay, it writes the data back to the database.
Resilient to database failures and can tolerate some database downtime
Risky as if the cache fails before the DB is updated, the data might get lost.
(Write-back strategy is used with other caching strategies to more advantage)

Cache Eviction

A cache eviction algorithm is a way of deciding which element to evict when the cache is full.
Some common cache eviction policies:

First In First Out (FIFO): First discards the first block accessed
Last In First Out (LIFO): First discards the block accessed most recently
Least Recently Used (LRU): First discards the least recently used items
Most Recently Used (MRU): First discards the most recently used items
Least Frequently Used (LFU): Counts how often an item is needed. Those that are used least often are discarded first.

Finally, lets list down some industrial examples. Some popular distributed caches used in the industry are Redis, Hazelcast, Eh-cache, Memcached, Riak, …

Some useful resources:

Caching Strategies and How to Choose the Right One
Distributed Cache 101
https://blog.eduonix.com/web-programming-tutorials/redis-memcached-select-caching-strategy/

Note:

This is my first article in steemit. This article contains findings that I found in my studies on distributed caching. Hope you learn something from this. Please comment below any suggestions. Thank you.

What is Distributed Caching ? (5 min read)