4.3 Cache Invalidation, Capacity, and Failover

Cache Invalidation, TTL Strategies & Mitigating Stampedes

Maintaining cache consistency requires careful key lifecycle management.

Time-to-Live (TTL) Expiration

Always assign a TTL to cached records using Redis expiration commands (SET key value EX seconds or EXPIRE key seconds). Without a TTL, abandoned or updated keys consume memory indefinitely until forced out by eviction.

Cache Stampede (Thundering Herd Problem)

A cache stampede occurs when an intensely accessed key expires, causing hundreds of concurrent client threads to simultaneously experience a cache miss and execute identical expensive queries against Cloud SQL, resulting in connection pool exhaustion and database collapse.

+--------------------------------------------------------------------------+
| Cache Stampede Mitigation: Distributed Mutex Locking                     |
+--------------------------------------------------------------------------+
|                                                                          |
| 1000 Concurrent Requests arrive for expired key 'catalog:item:42'        |
|         |                                                                |
|         v                                                                |
| [ Thread 1 ] ---> Acquires Redis Mutex: SET lock:42 NX PX 5000 (Success)  |
|         |                                                                |
|         +---> Queries Cloud SQL -> Updates Redis 'catalog:item:42' + TTL |
|         |                                                                |
|         +---> Releases Mutex Lock                                        |
|                                                                          |
| [ Threads 2-1000 ] -> Mutex Acquisition FAILS                            |
|         |                                                                |
|         +---> Sleep 50ms & Retry Cache OR Return Stale Value Gracefully  |
+--------------------------------------------------------------------------+

Stampede Defenses

1. Randomized TTL Jitter: Add random variance to key expiration windows to prevent synchronized mass expiration:

$$\text{Effective TTL} = \text{Base TTL} + \text{Random}(0, \text{Jitter Window})$$

1. Cache-Fill Coordination with Expiring Locks: When a cache miss occurs, the worker attempts to acquire an atomic distributed lock in Redis (SET lock:product:101 random_token NX PX 5000). Only a successful lock holder should refill the entry; release with a compare-and-delete check of the unique token so an expired holder cannot delete its successor's lock. Bound retries and tolerate duplicate cache fills. Such a lock is not a durable transaction or payment deduplication record.

---

Redis Maxmemory Eviction Policies

When a Memorystore for Redis instance reaches 100% of its provisioned memory capacity (maxmemory), its configured eviction policy dictates whether incoming writes succeed or fail.

---

Serverless Connectivity: VPC Access Connectors vs. Direct VPC Egress

Memorystore instances are provisioned exclusively with private RFC 1918 IP addresses inside your Virtual Private Cloud (VPC). They have no public IP addresses and cannot be reached over the public internet.

Because serverless runtimes (Cloud Run, Cloud Functions, App Engine standard) operate inside Google-managed multitenant networks, they cannot communicate with private VPC IPs out of the box.

+--------------------------------------------------------------------------+
| Serverless to Private Memorystore Networking                             |
+--------------------------------------------------------------------------+
|                                                                          |
| [ Cloud Run Service (Serverless Compute) ]                               |
|         |                                                                |
|         +--- Option A: Direct VPC Egress (Recommended - High Throughput) |
|         |              Attaches container network interface directly     |
|         |                                                                |
|         +--- Option B: Serverless VPC Access Connector                   |
|                        Routes packets via dedicated /28 connector VMs    |
|         |                                                                |
|         v                                                                |
| [ Customer VPC Network: 10.0.0.0/16 ]                                    |
|         |                                                                |
|         v                                                                |
| [ Memorystore for Redis Standard Tier HA (Private IP: 10.0.0.4:6379) ]   |
+--------------------------------------------------------------------------+

Option A: Direct VPC Egress (Recommended for Modern Cloud Run)

• Architecture: Cloud Run allocates network interfaces directly into your VPC subnet without requiring intermediary connector VMs.
• Benefits: Delivers lower latency, higher throughput (within Cloud Run instance and network throughput limits), and zero additional VM compute charges.
• Configuration CLI:

  gcloud run services update catalog-service \
      --network=custom-vpc \
      --subnet=serverless-subnet \
      --vpc-egress=private-ranges-only
  

Option B: Serverless VPC Access Connector

• Architecture: Provisions managed e2-micro or f1-micro proxy VMs within a dedicated, unallocated /28 subnet in your VPC.
• Throughput Limits: Scalable between 2 and 10 connector instances; total bandwidth is constrained by connector VM capacity.

---

High Availability, Replication & Automated Failover

Google Cloud offers two tiers for Memorystore for Redis:

Basic Tier

• Topology: Single standalone Redis node in a single zone.
• High Availability: None. No replication, no SLA. If the underlying host fails, memory is reinitialized and data is completely wiped.

Standard Tier (High Availability)

• Topology: Provisions a primary node in one zone and a cross-zone standby replica in a second zone within the same region.
• Replication: Asynchronous replication keeps the standby replica synchronized with the primary.
• Automated Failover: If the primary node fails or undergoes maintenance, Google Cloud detects the health probe failure and promotes the standby replica to primary after failure detection; failover commonly takes around 30 seconds and is not a fixed deadline.
• IP Endpoint Preservation: The connection IP address and port (10.x.x.x:6379) automatically repoint to the promoted node. Application containers do not need to re-resolve DNS or alter connection strings.

Official references checked October 18, 2026: Google Cloud 1.