Designing a cache health dashboard

WHAT THIS TESTS Whether you can select the metrics that actually indicate cache health and design a layout that an on-call engineer can scan under pressure, not just enumerate every exposed counter.

A GOOD ANSWER COVERS Key metrics: cache hit ratio, since a falling ratio signals a cold or thrashing cache; command latency percentiles such as p50 and p99, since latency is what callers feel; memory usage versus configured maxmemory; eviction and expiration rates, which reveal pressure; connected clients and rejected connections for saturation; operations per second by type; and replication lag plus role for clustered setups. Visualization choices: use stat or gauge panels for single critical current values like memory percent and hit ratio so they read instantly with color thresholds; use time-series graphs for anything where the trend matters, like latency, ops/sec, and evictions over time; use a table for per-node breakdowns in a cluster. Lay out top-down: overall health and SLO-style panels at the top, then resource and saturation, then detail. Add threshold coloring and a time-range that matches incident response.

COMMON WRONG ANSWERS Showing raw cumulative counters instead of rates. Listing dozens of low-value metrics with no prioritization, so the engineer cannot find the signal. Ignoring percentiles and showing only averages, which hide tail latency. No thresholds, so nothing visually flags a problem.

LIKELY FOLLOW-UPS How do you set thresholds? Which of these would you alert on versus only chart? How does the dashboard change for a sharded cluster?

ONE CONCRETE EXAMPLE The top row has three stat panels: hit ratio, used-memory percent, and p99 GET latency, each green/amber/red. Below, a time-series shows evictions and ops/sec, and another shows latency percentiles. During an incident the engineer instantly sees hit ratio dropped and evictions spiked, pointing to memory pressure rather than a network issue.