Staff / expert · Redis with Go
Hot keys, eviction and overload
Why does Redis latency rise even when Go CPU is low?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Time may be spent waiting for a pool connection, network I/O, a busy server, a large reply or a slow command. Inspect these stages separately and correlate with server latency/slow-command diagnostics.
Avoid blocking scans such as KEYS on large production keyspaces. SCAN is incremental but has weak snapshot semantics and can return duplicates; consumers need appropriate handling. Pipelines reduce round trips but can create large bursts.
Set memory/eviction and persistence policies based on whether data is disposable cache or authority. Hot keys, large values, retry storms and aggregate client concurrency can saturate capacity. Bound input, concurrency, deadlines and fallback work.
Common trap
A cache eviction policy that is acceptable for derived data can destroy authoritative job or coordination state.
Try it
Every service retries three times during a Redis slowdown. What can happen to total demand?
Worked solution
Attempts multiply precisely while capacity is low, increasing queues and latency. Bound attempts by a shared deadline, add jitter where retries are appropriate, and shed or degrade work according to the role of Redis. Measure original requests and attempts separately.
Change the constraint
How would a hot single key limit the benefit of adding cluster shards?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.