Redis Core
Foundational guidance for modeling data in Redis. Covers data-type selection and key-name conventions — the two decisions that most directly drive memory, performance, and maintainability.
When to apply
- Caching objects, sessions, or per-user state.
- Counters, leaderboards, recent-items lists, unique-membership sets.
- Reviewing or refactoring Redis key names.
- Deciding between a Redis Hash and a JSON document for an entity.
1. Choose the right data structure
Pick the type that matches the access pattern, not just the shape of the data.
Common anti-pattern: stuffing a flat object into a serialized string. Updating one field means fetch + parse + mutate + rewrite. Use a Hash instead.
See references/choose-data-structure.md [blocked] for full rationale and Python/Java examples.
2. Use consistent key names
Use colon-separated segments with a stable hierarchy:
Rules of thumb:
- Lowercase, colon-separated. No spaces, no mixed casing (
User_1001_Profileis bad). - Keep keys short but readable — keys live in memory and appear in every command.
- Don't use full URLs or long strings as keys. Extract a short identifier, or use a hash digest of the URL.
- Prefix for multi-tenancy (
tenant:42:user:7:cart) so scans and ACLs can target a tenant cleanly. - Be consistent. Pick one convention per service and apply it across all keys.
See references/key-naming.md [blocked] for cleanup examples and edge cases.
