Common caching strategies
The following are some notes explaining two common caching strategies.
Lazy Loading
Lazy Loading implements a simple concept. The data is only loaded into the cache when it is requested for the first time. If the data is not present in the cache (a cache miss), it is fetched from the primary data store (e.g., a database), returned to the requester, and then added to the cache for future requests.
Step by step breakdown
User
|
v
Application
|
v
+---------------------------+
| Check cache (e.g., Redis) |
+---------------------------+
|
v
Cache miss <-----if----> Cache hit ----> Return response
|
v
Query Primary Data Store (e.g., Postgres)
|
v
Store in cache
|
v
Return Data to User
Benefits of Lazy loading caching
- Simple to implement. No overhead on cache resources.
- Subsequent requests for the same data are faster since they are served from the cache.
- Cached data can be set to auto-expire after a certain period.
Things to consider
- The first request for data will be relatively slow because of the overhead of fetching from the primary data store.
- There is a chance of serving stale data if the cache hasn’t expired yet. This can be mitigated by force requesting a cache data update.
- Lazy loading require proper management of cache eviction policies and expiration times to balance performance (usage of cache) and data freshness (chances of serving stale data).
Write-Through
Write-Through is a caching strategy where data is written to the cache and the primary data store simultaneously. This ensures that the cache is always updated with the latest data.
Step by step breakdown
User
|
v
Application
|
v
+-----------------+ Write +-----------------------+
| Write to cache |<-------->| Primary data |
| (i.e, Redis ) | +----->| store (e.g., Postgres)|
+-----------------+ | +-----------------------+
|
v
+-------------+
| Check cache|
+-------------+
|
v
Cache Miss <------- Cache Hit
|
v
Query Primary Data Store
|
v
Store in Cache
|
v
Return Data to User
Benefits of write-through caching
- The cache and the primary data store are always synchronized.
- Data is always fresh on both sides, there is no risk of stale data in the cache.
Things to consider
- Chances of high latency since each write operation involves writing to both the cache and the primary data store.
- Constant writing operations to the cache can affect cache performance (i.e., increases the requirements for compute resources).
- Complexity in managing the consistency between the cache and the primary data store, especially in large scale systems.