Google Cloud services
14 / 24
Google Cloud

Caching — Memorystore for Redis

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

Memorystore is managed Redis (and Memcached), reachable privately from your VPC.

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]  -> under a millisecond
        -> cache [miss] -> database -> populate 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 costs latency rather than correctness.
4
Invalidation is the hard part.
    TTL only          simple, serves stale data for up to the TTL
    write-through     always fresh, slower writes
    delete-on-write   evict the key; the next read repopulates
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 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.
    Basic     a single node. No replica, no failover. Dev only.
    Standard  a replica in another zone, automatic failover
    Cluster   sharded, scales horizontally
8
Basic loses everything on a restart, and the full load lands on the database with a cold cache. Production starts at Standard.
9
It is VPC-private. Memorystore has no public endpoint — access is over a private IP from authorised networks, which removes a whole class of exposure but means serverless callers need a VPC connector.
10
That connector requirement catches people. Cloud Run and Cloud Functions reach Memorystore only through Serverless VPC Access or Direct VPC egress; without it the connection simply times out.
11
Beyond caching. Session state so services stay stateless, rate-limiting counters, distributed locks, and leaderboards via sorted sets.
12
What not to cache. Anything that must be exactly right when read — a balance at checkout — belongs in the database.
13
What the interviewer is probing.1. "Your Cloud Run service times out connecting to Memorystore. Why?" Probing: the networking requirement. Stalls: "The instance is down." Moves up: Memorystore is VPC-private with no public endpoint, so serverless callers need Serverless VPC Access or Direct VPC egress.
14
2. "Which tier for production?" Probing: the replica. Stalls: "Basic." Moves up: Standard — Basic has no replica and no failover, so a restart means a cold cache and full database load.
15
3. "Describe cache-aside." Probing: the pattern. Stalls: "Check the cache." Moves up: read the cache, fall back to the database and populate it with a TTL; the application owns the cache, so an outage costs latency rather than correctness.
16
4. "How do you prevent a stampede?" Probing: the failure mode. Stalls: "Longer TTLs." *Moves up:* a short lock so one request repopulates, plus jittered TTLs so hot keys do not expire together.
Use cases:memorystorerediscache-asidevpc-connectorttl