Capacity planning for a distributed cache

WHAT THIS TESTS: Whether you understand that a cache's capacity is governed by memory and effectiveness metrics, not just compute, and that you can build a forecasting model to scale proactively.

A GOOD ANSWER COVERS: The most important metric is the cache hit ratio, since a cache exists to serve reads cheaply; a declining hit ratio means the cache is too small for the working set or is evicting too aggressively, pushing load onto the backing store. Track memory usage and the eviction rate together: rising evictions with high memory utilization is the clearest signal you are running out of headroom. Track throughput (operations per second) and latency (p50/p99) to know when the nodes are saturated, plus key count, average item size, and connection counts. Establish baselines for normal behavior, then correlate these metrics with traffic and dataset growth to build a forecast: model the trend (and any seasonality, like daily or holiday peaks) to project when memory utilization or eviction rate will cross a threshold. Set scaling triggers ahead of that point so you add nodes or memory before the hit ratio degrades and the backing store gets overwhelmed. For a distributed cache, also consider rebalancing and resharding cost when adding nodes, and replication for availability.

COMMON WRONG ANSWERS: Watching only CPU and memory in the abstract while ignoring hit ratio and eviction rate, which are the true capacity signals for a cache. Scaling reactively after the hit ratio has already collapsed. Forgetting that adding nodes triggers rebalancing.

LIKELY FOLLOW-UPS: What hit ratio is 'good' and how does that depend on the workload? How do you forecast for seasonal spikes? What happens to the backing database when the cache hit ratio drops?

ONE CONCRETE EXAMPLE: A distributed cache shows memory utilization climbing 2% per week with evictions starting to tick up and the hit ratio slipping from 95% to 92%. The forecast projects memory saturation in six weeks, so you provision additional nodes now, restoring headroom and keeping the hit ratio high before the backing database sees a surge.