ElastiCache

Note

•

Using ElasticCache involves heavy application code changes

•

Can set cache TTL (time-to-live)

•

TTL is disadvantageous when using write-through

•

Lazy loading vs Write through: here

ElastiCache Overview

•

The same way RDS is to get managed Relational Databases…

•

ElastiCache is to get managed Redis and Memcached

•

Caches are in-memory databases with really high performance, low latency

•

Helps reduce load off of databases for read intensive workloads

•

Helps make your application stateless

•

AWS takes care of OS maintenance / patching, optimizations, setup, configuration, monitoring, failure recovery and backups

•

Using ElastiCache involves heavy application code changes

DB Cache

•

Applications queries ElastiCache, if not available, get from RDS and store in ElastiCache

•

Helps relieve load in RDS

•

Cache must hav en invalidation strategy to make sure only the most current data is used in there

User Session Store

•

User logs into any of the application

•

The application writes the session data into ElastiCache

•

The user hits another instance of our application

•

The instance retrieves the data and the user is already logged in

Caching Implement Considerations

•

Is it safe to cache data?

◦

Data may be out date, eventually consistent

•

Is caching effective for that data?

◦

Pattern: data changing slowly, few keys are frequently needed

◦

Ani patterns: data changing rapidly, all large key space frequently needed

•

Is data structured well for caching?

◦

example: key value caching, or caching of aggregations results

•

Which caching design pattern is the most appropriate?

Lazy Loading / Cache-Aside / Lazy Population

•

Pros

◦

Only requested data is cached (the cache isn’t filled up with unused data)

◦

Node failures are not fatal (just increased latency to warm the cache)

•

Cons

◦

Cache miss penalty that results in 3 round trips, noticeable delay for that request

◦

Stale data: data can be updated in the database and outdated in cache

Write Through - Add or Update cache when database is updated

•

Pros

◦

Data in cache is never stale, reads are quick

◦

Write penalty vs Read penalty (each write requires 2 calls)

•

Cons

◦

Missing Data until it is added / updated in the DB. Mitigation is to implement Lazy Loading strategy as well

◦

Cache churn - a lot of the data will never be read

Cache Evictions and Time-to-live (TTL)

•

Cache eviction can occur in three ways:

◦

You delete the item explicitly in the cache

◦

Item is evicted because the memory is full and it’s not recently used (LRU)

◦

You set an item time-to-live (or TTL)

•

TTL are helpful for any kind of data:

◦

Leaderboards

◦

Comments

◦

Activity streams

•

TTL can range from few seconds to hours or days

•

If too many evictions happen due to memory, you should scale up or scale out

Summary

•

Lazy Loading / Cache aside is easy to implement and works for many situations as a foundation, especially on the read side

•

Write-through is usually combined with Lazy Loading as targeted for the queries or workloads that benefit from this optimization

•

Setting a TTL is usually not a bad idea, except when you’re using Write-through. Set it to a sensible value for your application

•

Only cache the data that makes sense (user profiles, blogs, etc…)