To address the scalability issue mentioned in the prior section, you can abstract the HTTP sessions from the web servers themselves.
A common solution for this is to leverage an in-memory key/value store such as Redis or Memcached.
Web service used to deploy, operate, and scale an in-memory cache in the cloud
Improves the performance of web apps by allowing you to retrieve information from fast, managed, in-memory data stores, instead of relying on slower disk-based databases
Whenever possible, apps will retrieve data from ElastiCache and defer to databases when data isn’t found in cache.
|Simple cache to offload DB burden||YES||YES|
|Ability to scale horizontally for writes/storage||YES||NO|
|Advanced data types||NO||YES|
|Sorting/Ranking data sets||NO||YES|
|Multi-AZ with automatic failover||NO||YES|
|Persistent of data||NO||YES|
With write thru configured, if data is written to the db, the data in the cache will also be updated.
With this, the data in the cache will never stale. Because the data in the cache is updated every time it is written to the db, the data in the cache is always current.
When a db is written to, that same data is written to the cache in a write thru configuration.
Disadvantages of write thru:
Write pelnaty - Every write involves two trips, a write to the cache and a write to the db.
Missing data - When a new node is created to scale up or heal a failed node, the node doesn’t contain all data. Data will be still missing until it is added or updated in the db. In this scenario, you may choose to use lazy caching approach to repopulate the cache.
Unused data - Because most of data is never read, there can be a lot of data in the cluster that is never read.
Cache churn - The cache may be updated regular if certain records are updated repeatedlly.
Lazy loading is a caching strategy that loads data into a cache only when necessary. In this deployment, ElastiCache will sit between application and data store or database. When application requests a data, the application will ask in the ElastiCache for the data, if the data is presented, it will be sent back to application. If the data is not existed, it considered a cache
In case of cache miss, application will ask directly to data store or database.
The application will write the new data into cache. It can retrieve next time.
Cache miss pelnaty: each cache miss requires three trips, this can cause delay in response time.
If the data is only cached when there is a miss, data in the cache can become stale.
Lazy loading allows for stale data, while write thru ensure the data is always refresh but may populate the cache with unnecessary data. By adding TTL (Time to live), you can increase the benefits of caching, avoid clustering up the cache with data.
TTL is an integer value or key that specific the number of seconds or miliseconds, depend on the memory engine, until the key expires.
App query database for data when TTL expires
When an application attempts to read an expired key, it will be treated as not found the data in the cache, meaning that the database is required and cache is updated. This keeps data from getting too stale and requires that values in the cache are occasionally refreshed from the database.