Distributed session management with in-memory key/value stores

  • 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.

ElastiCache Wrapup

  • 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.

Use cases

  1. You are concerned about response times for your customer
  1. You find heavy-hitting, high-volume requests inundating your database
  1. You would like to reduce your database costs


Amazon ElastiCache options

Memcached Redis
Simple cache to offload DB burden YES YES
Ability to scale horizontally for writes/storage YES NO
Multi-threaded performance YES NO
Advanced data types NO YES
Sorting/Ranking data sets NO YES
Pub/Sub capacity NO YES
Multi-AZ with automatic failover NO YES
Persistent of data NO YES

Write thru


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:

  1. Write pelnaty - Every write involves two trips, a write to the cache and a write to the db.

  2. 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.

  3. Unused data - Because most of data is never read, there can be a lot of data in the cluster that is never read.

  4. Cache churn - The cache may be updated regular if certain records are updated repeatedlly.

Lazy Loading


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 "miss".

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.


  • Only cache the requested data, avoiding unnecessary cached data.


  • 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.