Cache (in-memory)
In-memory key-value store that answers hot reads and shields the database.
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): Redis, Memcached
In the guide
- Ch. 5 · Caching and Content Delivery p. 1
- Figures: 12, 13