Junior · Redis with Go
Redis client lifetime and missing keys
How do you distinguish a missing Redis key from an outage in Go?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Reuse a go-redis client and its pool; give operations bounded contexts and verify the chosen client options for context timeouts. Construction does not prove a server is reachable, so a bounded Ping serves a different purpose.
redis.Nil is the documented missing-value result for relevant commands, not a transport outage. Handle it separately from authentication, timeout and connection errors. Command-specific result contracts still matter.
Close the client after users finish, namespace keys by tenant and schema version where appropriate, and protect credentials. A Redis error should follow the system's explicit cache/authority policy, not become a silent default value.
Common trap
Treating every error as a cache miss can hide an outage and overload the primary database.
Try it
GET returns redis.Nil for one request and context deadline exceeded for another. How do their metrics differ?
Worked solution
Count the first as a cache miss and the second as a dependency error/timeout. If fallback is allowed, bound the additional origin load. Do not report a healthy cache hit ratio by discarding failed lookups.
Change the constraint
What would you do differently if Redis is the authoritative job store rather than an optional cache?
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.