Q05 proof · Cache strategies: Redis and Memcached

5. Cache strategies: Redis and Memcached

Answer as submitted

“Yes — Redis (cache-aside, TTL, pub/sub, cluster), plus Memcached and CDN caching.”

Technical decision: expand. The submitted line is accurate but compressed — the questionnaire caps each answer at one short line, so it names the technologies without the discipline behind them. This page is the separate, detailed version: it shows the exact operations, the implementation in code, and the rules that keep a cache from turning into a source of stale data.

Expanded answer

Yes. Redis is my primary distributed cache and I apply it with cache-aside reads, write-through updates and an explicit invalidation contract built on TTLs, jittered expirations and pub/sub invalidation. Memcached I use for the same key/value cache-aside model where a slim, non-persistent store is enough, and I add in-process IMemoryCache memoisation for the hot in-node layer plus HTTP/CDN caching at the edge.

Strategy	Typical operation	What it is for
Cache-aside (read)	`GET` → on miss `SETEX`	Serves repeated reads without touching the database.
Write-through	`SET … EX <ttl>`	Keeps the entry fresh after the database write succeeds.
Jittered expiry	TTL + random offset	Stops a whole keyspace from expiring in the same second.
Pub/sub invalidation	`PUBLISH` / `SUBSCRIBE`	Every node drops its own copy, so no stale replica survives.
Single-flight lock	`SET … NX PX`	Turns a stampede of misses into one database query.
In-process memoisation	`IMemoryCache`	Removes even the network hop for the hottest values.
Edge / HTTP caching	`Cache-Control`, `ETag`	Answers static and cacheable API responses before the origin.

Live cache workflow proof

The running component below changes its command/result view through real event binding. Select an operation to see the exact Redis command, what the application does around it, and the observable result the caller receives.

CACHE WORKFLOWRUNNING

Choose a cache operation

Select an operation to inspect the exact Redis command and its observable result.

$ GET user:42:profile

Cache-aside read: the value is in Redis, so the database is never touched and the request stays in the sub-millisecond range.

HIT  ·  0.4 ms  ·  TTL 267 s left
{"id":42,"name":"M. Cortes","plan":"senior"}

How caching fits this answer

Why an invalidation contract comes first. A cache is only as good as its worst stale read. Before adding one I define how entries expire and how they are invalidated — TTL plus jitter for normal expiry, an event for explicit invalidation, and a single-flight lock for the moment of a miss — and then I measure hit ratio and p95 latency to confirm the cache actually earns its complexity.

Boundary for Q05: this page covers caching technologies and the strategy around them. Cluster topology sizing, provider-specific failover configuration and cost modelling for managed Redis services are separate topics.

Source files

Select a file to inspect the proof with syntax highlighting and line numbers. The first file is the code running the component above; the other two are the production shapes of the same strategy.

Acceptance criteria

Names Redis and Memcached and the cache-aside model they share.
Distinguishes read-through, write-through, invalidation and lock operations.
Shows an interactive proof of choosing a cache operation and reading its result.
Documents the expiration and invalidation rules before the cache is introduced.
Defers cluster sizing, provider failover and cost modelling to a later topic.