Redis Key Naming Convention Design Prompt
Design a consistent, collision-free Redis key-naming scheme — namespaces, delimiters, versioning, and cluster hash-tag placement — that stays debuggable and safe to migrate.
- Target user
- Teams standardising Redis usage across services
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior engineer defining a Redis key-naming standard for multiple services sharing (or sharding) an instance.
I will provide:
- The services/teams that share the instance, and whether it is standalone or Redis Cluster
- Example keys in use today and any multi-key operations (MGET, transactions, Lua across keys)
- Whether keys need to be enumerated, migrated, or bulk-invalidated
Your job:
1. **Define the namespace hierarchy**: `{service}:{entity}:{id}:{field}` with a single consistent delimiter (`:` is the Redis convention). Reserve the first segment as a per-service prefix so no two teams collide.
2. **Standardise identifiers**: lowercase, no spaces, stable ids (not human names that change), and a documented order (entity before id). Ban embedding volatile data (timestamps that change meaning) in the key body.
3. **Version where schemas evolve**: include a schema/version token (`user:v2:42`) so a format change is a new namespace, not a risky in-place migration.
4. **Cluster hash tags**: to co-locate keys that must be operated on together (MGET/transaction/Lua), wrap the shared part in braces `{...}` — `{order:42}:items`, `{order:42}:total` hash to the same slot. Warn that over-using one tag creates a hot slot; under-using it breaks multi-key ops with CROSSSLOT.
5. **Keep keys enumerable safely**: a predictable prefix makes `SCAN MATCH prefix:*` cheap and targeted; forbid `KEYS` in app code.
6. **Bound key length and TTL policy**: reasonable length (memory + readability), and a documented default TTL per namespace.
7. **Produce a written table**: namespace, purpose, example, TTL, owner — plus a lint/regex teams can enforce in code review.
Mark DESTRUCTIVE or risky: renaming a live namespace without dual-write (breaks readers), putting a hash tag around a high-cardinality value (hot slot), and using `KEYS`/`RENAME` on prod for migration instead of `SCAN` + copy.
---
Services + standalone/cluster: [DESCRIBE]
Example keys today: [PASTE]
Multi-key ops in use: [DESCRIBE]
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Why this prompt works
Key naming looks trivial until two services collide, a cluster migration hits CROSSSLOT, or nobody can tell what u:42:x means at 3 a.m. This prompt produces a written, lintable convention with the two things people forget: a versioning scheme so schema changes are new namespaces, and correct hash-tag placement so co-operated keys share a slot without creating a hot shard.
How to use it
- Say standalone vs cluster first — cluster makes hash tags mandatory for multi-key ops.
- List the multi-key operations — they dictate which key parts must share a
{tag}. - Assign a per-service prefix — the cheapest way to prevent cross-team collisions.
Useful commands
# Audit current namespaces without blocking (never KEYS on prod)
redis-cli --scan --pattern 'user:*' | head
# Verify two keys land on the same cluster slot (hash tag working)
redis-cli CLUSTER KEYSLOT '{order:42}:items'
redis-cli CLUSTER KEYSLOT '{order:42}:total'
# Inspect a key's TTL and type during review
redis-cli TTL user:v2:42
redis-cli TYPE user:v2:42Example convention table
service namespace purpose TTL owner
auth auth:session:{uid} login session 30m auth-team
orders {order:<id>}:items line items (cluster) none orders-team
billing billing:invoice:v2:<id> versioned invoice 7d billing-teamCommon findings this catches
- Colliding prefixes across teams on a shared instance.
- Missing hash tags → CROSSSLOT on MGET/transactions in cluster.
- Over-broad hash tag → one hot slot.
- In-place schema change → readers break; version the namespace instead.
KEYS-based enumeration in app code.
When to escalate
- A namespace needs to move between physical instances — plan a dual-write + backfill migration.
- One slot is unavoidably hot — reconsider the sharding key, not just the name.
Related prompts
-
Redis Geospatial Index Design Prompt
Design a Redis geospatial index — GEOADD/GEOSEARCH modeling, sharding, precision, and memory trade-offs — for proximity search at scale.
-
Redis Cluster Sharding Design Prompt
Design Redis Cluster sharding — 16384 hash slots, resharding, hash tags, and multi-key operation constraints across shards.
-
Redis Bitmap Analytics Design Prompt
Design memory-efficient real-time analytics with Redis bitmaps — daily active users, retention, and feature flags — using SETBIT/BITCOUNT/BITOP and BITFIELD counters.
-
Redis Cache Invalidation Strategy Design Prompt
Design a correct cache-invalidation strategy for Redis — write-through vs write-behind vs cache-aside, versioned keys, and event-driven busting — so stale reads never outlive the source of truth.
More Redis prompts & error guides
Browse every Redis prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.