This document discusses strategies for improving performance and scaling read workloads by implementing a cache layer using Elasticache. It notes that read replicas have scaling limitations and cost implications. It then provides details on caching strategies like write-through, lazy loading, and write behind that can be used. It also mentions other potential solutions like using purpose-built databases, S3 with CloudFront as a cache, optimizing queries, and GraphQL.

1. Moving towards 100k Orders Version 1.0
Data layer
Cache options

2. Problems to solve
1 Read heavy workloads
Bottlenecks on Read Replicas
2 RR scaling limitations
RR Cost implications
3 Slow / unoptimized queries
4 Unavailability
- Standard cache layer
- Architecture patterns like
Circuit Breaker

3. There are only two hard things in Computer
Science: cache invalidation and naming things.
https://martinfowler.com/bliki/TwoHardThings.html

4. ● TTLs
○ Volatile-lru / volatile-ttl
● 245,000 RPS with R5.xLarge @ 100
connections
● 238,000 RPS @800 connections
● Atomic Operations
Cache Layer
Universal truth!
● Messaging Queues / Pub-Sub model
● Native Sorting! (Sorted Sets)
● Lists
● 500MB objects
● Single Threaded
https://d0.awsstatic.com/whitepapers/performance-at-scale-with-amazon-elasticache.pdf

5. Caching Strategies
Write-through
Synchronous Updates
Lazy Loading
Check cache, if empty then fill
Write Behind
Write in Cache first
Read Replica
Copy via Enterprise Bus

6. Other Solutions
● Purpose built Databases
● S3 + CloudFront as cache for LLOs
● Perfectly optimized SQL queries
● GraphQL
https://aws.amazon.com/getting-started/hands-on/purpose-built-databases/