Memorystore (Redis/Valkey)

Managed in-memory cache.

Problem it solves: Repeated reads of the same data overload the database and add latency.

Where it sits: Between a service and its database (cache-aside).

When to use

  • Read-heavy workloads with a skewed access pattern.

When not to use

  • Data that must be read strongly consistent on every access, unless invalidation is solved.

Failure modes

  • Cold cache or mass expiry: the database receives the full load (stampede).
  • Stale data after writes without invalidation.

Metrics to watch

  • Hit ratio (%)
  • Evictions/s
  • Memory used
  • Downstream requests saved (req/s)

Alternatives

  • Read replicas
  • CDN
  • Materialised views

Configuration in Labs (illustrative defaults)

  • Instances (count) = 2 — Identical copies behind this logical component. Capacity scales linearly in this model.
  • Capacity per instance (req/s) = 50000 — Maximum requests one instance completes per second before it saturates.
  • Steady-state hit ratio (0–1) = 0.8 — Fraction of requests served from the cache once warm. Misses go downstream.
  • Hit latency (ms) = 1 — Time to answer a request that hits the cache.
  • Warm-up time (s) = 30 — When the cache starts cold, the hit ratio grows linearly to its steady-state value over this time.

Vendor examples (pattern only): Google Cloud managed service. Simulated as a generic “Cache (in-memory)”.

In the guide