.png&blockId=58207df4-1b5c-483c-b460-17d28299df63)
.png&blockId=58207df4-1b5c-483c-b460-17d28299df63&width=256)
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…)
