redislisted

# Redis Redis is fast because it's in-memory and ephemeral — treat it as a cache/derived store, never the source of truth. The craft is choosing the data structure that makes the operation O(1), the caching pattern that stays consistent with the database, and the eviction policy that fails gracefully when memory fills. > Summarize a verbose `redis-cli INFO` into health + flags: > `redis-cli INFO | python3 scripts/analyze_info.py` ## Pick the structure that fits the access | Need | Structure | Why | |---|---|---| | cache one value / counter | String (`GET/SET`, `INCR`) | atomic counter for free | | object with fields | Hash (`HSET/HGET`) | update one field without re-serializing | | queue / recent list | List (`LPUSH/RPOP`) | O(1) ends; `BRPOP` blocks for a worker | | unique membership | Set (`SADD/SISMEMBER`) | dedupe, set algebra | | leaderboard / time-ordered | Sorted Set (`ZADD/ZRANGE`) | score-ordered, O(log n) rank | | event log / fan-out | Stream (`XADD/XREAD`) | durable, consumer groups | Using a String + JSON where a Hash fits means re-reading and re-writing the whole blob to change one field. Match the structure to the operation. ## Cache-aside — the default pattern ```python def get_user(uid): key = f"user:{uid}" # namespace:entity:id cached = r.get(key) if cached is not None: return json.loads(cached) # hit user = db.fetch_user(uid) # miss → source of truth r.set(key, json.dumps(user), ex=300) # po