A caching layer keeps frequently accessed data in fast, temporary storage between an application and its primary data store. Serving reads from memory can reduce database load, response time, and the cost of scaling the primary store. section 11.0 section 11.7
A game leaderboard
A popular game may read and update scores too often for a relational database to rank players cheaply and quickly. Redis can hold the leaderboard in a sorted set, ordered by score, while the relational database remains the primary store. Player profiles and other heavily read metadata can also be cached. section 11.0
Cached data needs a freshness strategy. Items can expire after a set time, or a write-through strategy can update the cache when data is written. When memory fills, items may be evicted. Choose these behaviors with the application’s tolerance for stale or missing cached data in mind. section 11.7
For an AWS deployment, separate the cache engine from the operational choices:
- ElastiCache runs Memcached or Redis clusters. Memcached is a simpler key-value store; Redis supports structures such as sorted sets. MemoryDB is a Redis-compatible alternative with strong persistence guarantees. section 11.7
- Watch ElastiCache metrics in CloudWatch, including CPU utilization, swap usage, evictions, and—on Redis read replicas—replication lag. For Redis CPU, check EngineCPUUtilization: overall CPU can conceal a fully utilized core. section 11.5 section 11.5.1
- If the cache becomes a bottleneck, consider a larger node, sharding or read replicas, or compressing stored and transferred data. Swapping to disk can undermine the speed expected from an in-memory cache. section 11.6 section 11.5.1
A forum cache
A Discourse deployment uses PostgreSQL as its main data store and Redis for cached and transient data. Its CloudFormation deployment includes a cache cluster alongside the database, network, and application virtual machine. section 11.4
$ sudo amazon-linux-extras install -y redis6 #1 $ redis-cli -h $CacheAddress #2 > SET session:gamer1 online EX 15 #3 OK > GET session:gamer1 #4 "online" > GET session:gamer1 #5 (nil) #6 > ZADD highscore 100 "gamer1" #7 (integer) 1 > ZADD highscore 50 "gamer2" #8 (integer) 1 > ZADD highscore 150 "gamer3" #9 (integer) 1 > ZADD highscore 5 "gamer4" #10 (integer) 1 > ZRANGE highscore -3 -1 WITHSCORES #11 1) "gamer2" #12 2) "50" 3) "gamer1" 4) "100" 5) "gamer3" 6) "150" > quit #13
The Redis CLI example sets an expiring gamer session, confirms that it disappears, then adds scores to a sorted set and reads the high-score entries. section 11.1.2
