Redis Health Check Component Design
Design a Redis health check component that monitors connection status, latency, memory usage, and key eviction rates for caching and session store layers.
Component Checks
Detailed Explanation
Redis Health Check
Redis health checks verify that your caching layer or session store is operational. Since Redis is often used as a performance optimization, a failed Redis check may result in degraded rather than down status.
Response Component
{
"redis": {
"status": "UP",
"duration": "3ms",
"message": "Redis connection established",
"details": {
"version": "7.2.3",
"usedMemory": "45MB",
"maxMemory": "256MB",
"connectedClients": 12,
"hitRate": "94.5%"
}
}
}
What to Check
- PING response: Basic connectivity test
- Latency: Round-trip time for operations
- Memory usage: Percentage of maxmemory consumed
- Eviction rate: Are keys being evicted unexpectedly?
- Connected clients: Near connection limit?
Implementation Pattern
async function checkRedis() {
const start = Date.now();
try {
const pong = await redis.ping();
const info = await redis.info('memory');
const duration = Date.now() - start;
return {
status: pong === 'PONG' ? 'UP' : 'DOWN',
duration: `${duration}ms`,
message: 'Redis connection established'
};
} catch (error) {
return {
status: 'DOWN',
duration: `${Date.now() - start}ms`,
message: error.message
};
}
}
Health Thresholds
| Metric | Healthy | Degraded | Unhealthy |
|---|---|---|---|
| PING latency | < 5ms | 5-50ms | > 50ms / timeout |
| Memory usage | < 70% | 70-90% | > 90% |
| Hit rate | > 80% | 50-80% | < 50% |
| Eviction rate | 0/s | < 100/s | > 100/s |
Should Redis DOWN = Service DOWN?
It depends on your architecture. If Redis is only a cache with database fallback, treat it as DEGRADED. If Redis is your primary data store or session store with no fallback, treat it as DOWN.
Use Case
Applications using Redis for caching, session management, or as a message broker where cache unavailability impacts performance but may not require full service shutdown.