Stop 06 · Database ServicesTopics · 7/10

Caching Layers (ElastiCache / Redis)

Part of the Cloud Computing Roadmap

In short

The same 50 products get viewed a million times a day. Asking the database each time is wasteful. A cache keeps hot answers in memory and replies in well under a millisecond.

An in-memory data store sitting in front of a database to serve frequently-accessed data with far lower latency — reduces database load and dramatically speeds up read-heavy application paths.

The blob character stirs a pot and reaches for a steel spice box beside the stove.

Think of it like this

The masala dabba on the counter

Haldi, jeera and mirchi live in the masala dabba right next to the stove, not in the storeroom. You grab them in a second while cooking. The storeroom still has everything; the counter has what you use most. That's a cache.

Watch it happen

Cache-aside, step by step

App
Redis
Database

GET product:42

1/6The app checks the cache first.

The big ideas

What you need to know

In-memory speed

Redis and Valkey keep data in RAM, so reads are far faster than a disk-based database query.

TTL keeps it fresh

Every cached key should expire. A short TTL limits how long users can see stale data.

Invalidate on change

When the product changes, delete or update its cache key so the next read fetches the new value.

Managed options

ElastiCache (Redis OSS, Valkey, Memcached), Azure Cache for Redis and Google Memorystore run it for you.

See it in code

Walk through the code

python
1import json, redis2 3r = redis.Redis(host="my-cache.example.cache.amazonaws.com", port=6379, ssl=True)4 5def get_product(pid, db):6    key = f"product:{pid}"7    cached = r.get(key)8    if cached:9        return json.loads(cached)          # hit: straight from memory10    row = db.fetch_product(pid)            # miss: ask the database11    r.set(key, json.dumps(row), ex=300)    # keep it for 5 minutes12    return row13 14def update_product(pid, data, db):15    db.save_product(pid, data)16    r.delete(f"product:{pid}")             # next read refills the cache

1/4Connect to the managed cache with TLS, from inside the same VPC.

Cache-aside: the app reads the cache, falls back to the database on a miss, and clears the key whenever the data changes.

Save yourself the pain

Common mistakes

Oops

Caching without any expiry.

Do this instead

Always set a TTL. Without one, stale data and memory use grow forever.

Oops

Treating the cache as the only copy of important data.

Do this instead

Caches can be flushed or restarted. The database stays the source of truth.

Your mission

Measure a cache hit

~30 min

Quick check

An admin updates a product's price, but users keep seeing the old one for 10 minutes. What's the best fix?

Go deeper

  1. 1Set up a managed Redis instance and practice basic get/set operations.
  2. 2Learn the cache-aside pattern: check cache first, fall back to database, then populate cache.
  3. 3Understand cache invalidation as the hardest part of caching correctly.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge