Middle · Redis with Go
Cache invalidation and expiration
How do you prevent stale data from living forever?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Set value and expiry atomically when the command supports it; SET followed by EXPIRE has a crash window. Choose TTL from acceptable staleness and add jitter when synchronized expirations would create a herd.
Cache-aside reads can race with writes and slow refreshes. Define invalidation/versioning and whether stale serving is allowed; deleting a key after a write is not a universal proof against old data being refilled later.
Use bounded negative caching for valid not-found results, keyed by authorization scope. Collapse repeated loads and bound origin concurrency. A cache is only optional if the fallback can survive its absence.
Common trap
A long TTL improves hit rate while potentially violating the freshness contract.
Try it
An old database read finishes after a new write invalidates the key. What can it do?
Worked solution
It can repopulate stale data. Options include versioned values/keys, conditional publish of refreshes, or a carefully designed invalidation protocol. State the consistency promise and test this interleaving explicitly.
Change the constraint
How would you protect the origin during a full cache cold start?
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.