Domain 4 › Topic 17
⭐⭐⭐ Important for Read Optimization

🚀 Amazon ElastiCache

ElastiCache provides fully managed in-memory caching using Redis or Memcached. It dramatically improves read performance by caching frequently accessed data in memory, reducing database load and response times.

🔑 Covers: Redis vs Memcached · Caching Strategies · Lazy Loading · Write-Through · Session Store

🚀 What is ElastiCache?

Amazon ElastiCache
A fully managed service that provides in-memory data storage using either Redis or Memcached. "In-memory" means data is stored in RAM (not disk), making reads extremely fast — sub-millisecond vs milliseconds for a database. ElastiCache sits between your application and database, caching frequently read data so the database doesn't get hit for every request.
ElastiCache as a Caching Layer Between App and Database
📱App Request
→
🚀ElastiCacheCheck cache first
✅Cache HIT!Return in <1ms
|
❌Cache MISSNot in cache
→
🗄️RDS Database5-50ms query
→
💾Store in cacheReturn to app

🔴 Redis vs 🟦 Memcached — Which to Choose

🔴 Redis

  • Rich data structures: strings, lists, sets, sorted sets, hashes, bitmaps
  • Persistence: can save data to disk (RDB snapshots, AOF)
  • Replication: Primary + replica nodes for read scaling
  • Multi-AZ with automatic failover
  • Pub/sub messaging support
  • Lua scripting
  • Supports TLS encryption
  • Best for: session stores, leaderboards, real-time analytics, rate limiting, queues

🟦 Memcached

  • Simple key-value storage only (strings)
  • No persistence (data lost on restart)
  • Multi-threaded (can use multiple CPU cores)
  • Horizontal scaling via consistent hashing
  • No replication (simpler architecture)
  • Slightly simpler and faster for basic use cases
  • Best for: simple object caching where you only need put/get, no complex data
🎯 Exam Rule — Redis vs Memcached
If the question mentions: persistence, multi-AZ, replication, failover, complex data types (sorted sets), pub/sub, Lua scripting, or geospatial data → Use Redis.
If the question is a simple use case with no special requirements and mentions "multi-threaded" → Memcached is acceptable but Redis works too.
When in doubt, Redis is usually the better answer (richer feature set).

📐 Caching Strategies

1. Lazy Loading (Cache-Aside)

The most common strategy. Load data into cache only when requested (on cache miss).

1

App requests data from cache

Check ElastiCache for the key.

2

Cache miss → go to database

If key not in cache, query the database.

3

Store result in cache

Write the database result to ElastiCache with a TTL, then return to app.

✅ Pros

Only cache what's actually requested. Cache doesn't fill up with unused data. Easy to implement.

❌ Cons

First read always slow (cache miss → DB query → cache write). Cache may be stale if DB is updated without cache invalidation.

2. Write-Through

Every time data is written to the database, also write it to the cache simultaneously.

✅ Pros

Cache is always fresh — no stale data. Read performance is always fast (cache always has data).

❌ Cons

Cache fills up with data that might never be read. Write operations are slower (must write to both DB and cache). Cache may be large and expensive.

💡 Common Pattern — Combine Both
Use Write-Through for frequently written data you know will be read. Use Lazy Loading as the fallback for everything else. This gives fresh data for known hot data and on-demand loading for everything else.

Session Store Use Case

ElastiCache Redis is the standard solution for storing user sessions in distributed applications:

  • User logs in → session data stored in Redis with TTL (e.g., 30 minutes)
  • Any web server can read the session from Redis → enables stateless horizontal scaling
  • When session expires (TTL) or user logs out → delete from Redis
  • Without Redis: users would be logged out if their request hits a different server
← VPC Flow Logs