Microsoft Azure services
14 / 24
Microsoft Azure

Caching — Azure Cache for Redis

Put a managed Redis in front of a database, and handle invalidation and failure properly.

Azure Cache for Redis is managed Redis, used to keep hot reads off the database.

A chef keeping prepped ingredients within reach rather than walking to the cold store for every order, and discarding anything that has sat out too long.

Key Concepts

1
    app -> cache [hit]  -> returned in under a millisecond
        -> cache [miss] -> database -> write to cache -> return
2
Cache-aside is the pattern to describe.
    value = cache.get(key)
    if value is None:
        value = db.query(...)
        cache.set(key, value, ttl=300)
    return value
3
The application owns the cache, so a cache outage degrades latency rather than breaking correctness.
4
Invalidation is the part interviewers push on.
    TTL only          simple, serves stale data for up to the TTL
    write-through     update on every write; always fresh, slower writes
    delete-on-write   evict the key, let the next read repopulate
5
Delete-on-write is the usual compromise.
6
The three failure modes worth naming.
    stampede      a hot key expires and every request hits the
                  database at once. Fix with a short lock or
                  jittered TTLs.
    penetration   repeated misses for a key that does not exist.
                  Cache the negative result.
    avalanche     many keys expire together. Add jitter.
7
The tiers decide what you can rely on.
    Basic      single node, no SLA, no replication. Dev only.
    Standard   primary/replica, automatic failover, SLA
    Premium    clustering, persistence, VNet injection, zones
    Enterprise Redis Enterprise, active geo-replication, modules
8
Basic has no replica, so a node restart is a cold cache and the full load lands on the database. Production starts at Standard.
9
Clustering is Premium and up, and it changes the programming model: multi-key operations must stay within one hash slot, so {customer:123}:orders style key tagging becomes necessary.
{customer:123}:orders
10
Beyond caching. Redis is also the natural home for session state so app servers stay stateless, for distributed locks, for rate-limiting counters, and for leaderboards via sorted sets.
11
What not to cache. Anything that must be exactly right at the moment it is read — a balance at checkout — belongs in the database.
12
What the interviewer is probing.1. "Which tier is the minimum for production?" Probing: the replica. Stalls: "Basic is fine to start." Moves up: Standard — Basic is a single node with no replica and no SLA, so a restart is a cold cache and full database load.
13
2. "Describe cache-aside and why it is resilient." Probing: the pattern. Stalls: "Read from cache first." Moves up: the application reads the cache, falls back to the database and populates it; because the application owns the cache, an outage costs latency not correctness.
14
3. "What changes when you enable clustering?" Probing: the programming model. Stalls: "More memory." Moves up: multi-key operations must stay within one hash slot, so keys need tagging like {customer:123}:orders.
15
4. "A hot key expired and the database spiked. What is the fix?" Probing: the stampede. Stalls: "Longer TTL." Moves up: a short lock so one request repopulates, and jittered TTLs so keys do not all expire together.
Use cases:rediscache-asideinvalidationclusteringttl