Lazy Loading in ElastiCache

🔹 Lazy Loading in ElastiCache

Lazy loading is a caching pattern where data is loaded into the cache only when it is requested for the first time.

Here’s how it works in Amazon ElastiCache (Redis or Memcached):

1. App requests data → Check cache first.
2. If data is in cache (cache hit) → return it immediately.
3. If data is NOT in cache (cache miss) →

• Fetch it from the database (or another backend).
• Store it in the cache for next time.
• Return it to the application.

---

🔹 Example

Imagine you’re caching user profiles in ElastiCache Redis.

• Request for user:123 profile → not in cache → app queries RDS MySQL → stores result in Redis → returns profile.
• Next request for user:123 → found in Redis (cache hit) → super fast, no DB query.

---

🔹 Pros & Cons

✅ Pros

• Easy to implement.
• Reduces DB load after first access.
• Data is only cached if it’s actually used (no wasted cache space).

❌ Cons

• First request = cache miss → slower, since it hits the DB.
• If cached data expires/evicts → you’ll get another cache miss (but then re-cached).
• Doesn’t proactively refresh cache → may serve stale data until it’s invalidated.

---

🔹 Related Patterns

• Write-through cache → Data is written to cache and DB at the same time. Ensures cache is always warm, but writes are slower.
• Lazy loading (cache-aside) → Cache filled only on reads (what you asked about).
• Write-behind → App writes only to cache, and cache writes back to DB asynchronously.

---

✅ Lazy loading = Cache-aside pattern → fetch on demand, populate cache only when needed.

---

Other loading types

---

🔹 1. Lazy Loading (Cache-Aside)

• Data loaded into cache only on demand (read).
• If not in cache → fetch from DB → put in cache → return.
• Pros: Only stores what’s used.
• Cons: First request = slow (cache miss).

---

🔹 2. Write-Through Caching

• Every time data is written to DB, it’s also written to the cache immediately.
• Cache is always warm, so reads are fast.
• Pros: No cache miss for fresh data.
• Cons: More write latency (every write goes to cache + DB), cache may store rarely used data.

---

🔹 3. Write-Behind (Write-Back) Caching

• App writes only to cache first.
• Cache writes back to the DB asynchronously later.
• Pros: Super-fast writes, reduced DB load.
• Cons: Risk of data loss if cache node fails before writing to DB; more complex.

---

🔑 Quick Comparison Table

Strategy	Reads	Writes	Cache Warm?	Cons
Lazy Loading	Cache miss → DB	Normal DB writes	No (loaded on demand)	First request is slow, possible stale data
Write-Through	Always fast	DB + cache write each time	Yes (always updated)	Higher write latency, may cache unused data
Write-Behind	Always fast	Cache first, DB async later	Yes (recent writes in cache)	Risk of data loss if cache crashes before DB sync