The document discusses the cache-aside pattern in cloud design, emphasizing its role in optimizing resource usage and improving application performance. Key topics include strategies for managing cached data consistency, common access patterns like read-through and write-through, and the importance of understanding expiration policies and eviction strategies. It also highlights the applicability of this pattern, as well as example implementations using technologies like Redis and Spring.

1. Cache Aside
Siva Rama Krishna
Cloud Design
Patterns Series

2. @sivachunduru
linkedin.com/in/chunduru
slideshare.net/sivachunduru
2
$> who am i
Solution Specialist
Oracle Cloud Platform

3. 3
Motive of a pattern
Optimal use of resources Improvement in application
performance
Better Resiliency quotient

4. Context
• To deal the repeated access of
information in data store.
Challenge
• To ensure the cached data is always
consistent with the data in the data
store.
4
Background of Cache
CACHE

5. Background of Cache
• Application(s) strategy should,
– ensure that the data in the cache is as up-to-date as possible
– detect and handle situations that arise when the data in the cache has become stale
5

6. Cache – common access patterns
• Cache-as-DS**
–Read-through
–Write-through
–Write-behind
6
Many of commercial
caching systems
provide these patterns
out of the box
** DS = Data Store
Cache is the primary system of record

7. Cache-as-DS
• Read-through
– The cache is configured with a loader piece that knows how to load data from DS
– If the requested data doesn’t exist in cache, loader components loads from DS
• Write-through
– The cache is configured with a writer piece that knows how to write data to DS
– If the cache is asked to store a value for a key, the cache invokes the writer to store
the value in the DS, as well as updating the cache
• Write-behind
– This changes the timing of the write to the DS
– Basically, it queues the data for writing at a later time
7

8. What if the cache system doesn’t provide?
8

9. It’s the responsibility
of the application
that use the cache
to manage the data

10. ….means, application code
uses the Cache
directly

11. So, the need of Cache Aside
• An application must emulate the functionality of
– Reading values
– Writing values
• This strategy loads or evicts the data into the cache on demand.
• One can choose Pre-load of data or LAYGO (decide on case by case)

12. • Check if the item exists in the cache
Cache Aside – Reading illustration
Cache
Data Store
???
• If doesn’t exists, read the item from
data store
• Store a copy of the item in the
cache
AppWhen Application reads the item,

13. value = cache.get (key)
if (value == null) {
value = datasource.get (key)
cache.put (key, value)
}
Cache Aside – Reading – Pseudo code

14. • Make the change to data store
Cache Aside – Writing illustration
Cache
Data Store
X
• Invalidate the item in the cache
When Application updates the item, App
• For the next READ of the item,
application uses Reading pattern

15. datasource.put (key, value)
cache.put (key, value)
value = newValue
datasource.put (key, value)
cache.invalidate (key)
Cache Aside – Writing – Pseudo code

16. Issues & Considerations
16

17. Life time of cached data
17
Don't make the
expiration period
too short
Don't make the
expiration period
so long
It cause applications to
regularly retrieve data
from DS and add to cache
It cause the cached data
likely to become stale
Caching is most effective for relatively static data or data that is read frequently
• Expiration Policy - to invalidate and remove inactive data from cache
• To be effective, the expiration policy must match the pattern of data access

18. Least-recently-used policy Global expiration policy with customizations
Evicting data
• Cache size is mostly lesser size than DS size – Data eviction is obvious
• Various eviction policies –
18
It isn't always appropriate to apply a global eviction policy to every item
Ex:- if a cached item is very expensive to retrieve from the DS, it is better to keep that
item in the cache at the expense of more frequently accessed but less costly items

19. Priming the cache
• Many solutions pre-populate the cache with the data that an application is
likely to need as part of the startup processing.
19
Data
Store
CACHE
Cache-Aside pattern can still be useful if some of this data expires or is evicted

20. Consistency
• This pattern doesn't guarantee consistency between the DS & the cache
20
Org.
Boundary
Data
Store
External
Process
update (value)
Cache
X
X

Data
Store

21. Local (in-memory) caching
21
• A cache could be local to an application instance and stored in-memory.
• Cache-Aside can be useful in this environment if an application repeatedly
accesses the same data.
Local Cache is
private; each app
instances have a copy
of same data
This data can quickly
become inconsistent
between caches;
expire and refresh
frequently
Consider investigating the use of a shared or distributed caching mechanism

22. Applicability of Cache-Aside pattern
22

23. Suitable when
• A cache doesn't provide native read-through and write-through operations.
• Resource demand is unpredictable. This pattern enables applications to
load data on demand.
• It makes no assumptions about which data an application will require in
advance.
23

24. Not Suitable when
• The cached data set is static ONLY. Use the CDN, if so.
• Caching session state information in a web application hosted in a web
farm. In this environment, you should avoid introducing dependencies
based on client-server affinity.
24

25. Example implementations
Coherence
25

26. Read-thru
26

27. Write-thru
27

28. Write-behind
28

29. Example implementations
Spring
29

30. • When getRecordForSearch is called,
it will be fetched automatically
from the cache if it is available (it
will not hit the method code at all).
• Otherwise, it will be retrieved from
the data store.
Read-thru in Spring

31. Read-thru in Spring
31

32. • When a method to update the data
in the data store is called, it also
invalidates the cache entry using
the key.
• In this approach, the cache entry
gets loaded only when it is re-
requested after the update.
• Cache entries can also be updated
if and when the data is updated in
the data store to get faster data
retrieval and consistency in one go.
32
Write-thru in Spring

33. 33
Write-thru in Spring

34. Example implementations
Redis Cache
34

35. Redis - Overview
• Redis is an
– open-source
– in-memory key-value data store
• Redis is used as
– a database
– cache
– message broker
• In terms of implementation, Key-Value stores represent one of the largest
and oldest members in the NoSQL space
• Redis supports data structures such as strings, hashes, lists, sets, and
sorted sets with range queries.

36. <dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
36
SpringBoot – Redis integration

37. 37
DEMO

38. Pull Redis docker image

39. 39
Create Redis configuration and start container

40. 40
Explore and Run SpringBoot application

41. 41
Retrieve the record that qualifies for caching

42. • Out of 5 requests, 1st request was
served from DS and rest of 4
requests were served from Cache
42
Check in cache about a new entry

43. 43
Retrieve the record that doesn’t qualify for caching

44. • Optimal usage of
resources
• Improve the application
performance
• Resiliency in application
behavior
Summary - Motive of the pattern
• Optimal Caching • Optimal READ Operations • Pre-load data (or) LAYGO

45. 45