Key Space Distribution By Prefix

Command availability

Tier A: Triage with CloudWatch and scope the scan

Step 1: CloudWatch signal check

Query BytesUsedForCache and CurrItems trend. If both flat and within range, analysis may not be urgent. If memory-per-key is rising or both climbing together, proceed.

Stop condition: If CloudWatch shows no growth and concern is theoretical, consider a sampled scan only.

Step 2: Get a size estimate

Node-based cluster mode: run DBSIZE against each primary, sum results.

Step 3: Decide scan strategy

Step 4: Identify delimiter and prefix depth

Common conventions: : (app:module:id), / (URL-shaped), | (legacy). Start with depth 1.

Stop condition: If a sample of 100 keys shows no consistent separator, aggregate by first N characters and flag “no structured naming” as output.

Tier B: Narrow with client-side sampling

Minimal shell pattern (prefix-depth 1, : delimiter)

For richer aggregation (per-type counts, cardinality sum), use a Python or Bash script that calls TYPE per sampled key with proper key escaping. The minimal awk pipeline above is safe for prefix counting; per-type aggregation with shell pipelines breaks on keys containing spaces, quotes, or special characters.

Run against a replica endpoint on node-based clusters.

Cost and impact

Same safety class as valkey-cli --bigkeys: cursor-bounded, read-only, stoppable. Stop if EngineCPU rises >10 percentage points.

Serverless: run off-peak. Every sampled key consumes ECPUs.

Interpret the output

• Count = volume. Over a million small session keys is normal. Tens of thousands of untracked _tmp: keys with no TTL is a leak.
• Sum cardinality approximates memory load.
• Max catches big-key outliers hiding in an otherwise normal prefix (route to big-key-hunter.md).

Stop condition: If distribution is uniform (within an order of magnitude, no type surprises, no unexpected prefixes), the keyspace is healthy.

Tier C: Verify with MEMORY USAGE (node-based only)

Step 1: Sample keys from the hot prefix

Step 2: Measure byte footprint

Step 3: Extrapolate

If 100 sampled keys from a 1,245,000-key prefix average 4,200 bytes, the prefix uses ~5GB. Validate against the BytesUsedForCacheItems CloudWatch metric (node-based).

TTL Audit Extension

Run alongside Tier B in the same SCAN loop. Adds ~10-15% runtime. TTL and EXPIRETIME are O(1).

Augmented output

TTL hygiene signals

• Keys without TTL in a prefix that should be volatile: application lost track
• All keys without TTL in unknown prefix: strong orphan signal (deprecated feature, crashed job)
• Bimodal TTL distribution: two writers with inconsistent policy

Remediation for TTL problems

1. Application-level fix (default): add EX to the SET/HSET/SADD that writes without TTL
2. Backfill TTL: run batched EXPIRE during off-peak
3. Enforce conventions: document TTL policy per prefix, review in code review
4. Bulk cleanup: UNLINK orphan prefixes in batches (non-blocking)

Remediation for prefix distribution problems

1. TTL hygiene (default): shorten or enforce TTL on the bloated prefix
2. Application cleanup: UNLINK deprecated/orphan keys in batches
3. Move to different tier: large blobs that don’t benefit from cache semantics belong in S3/DynamoDB
4. Split to separate cache: when one tenant/prefix dominates (>30% of memory). If resharding within a cluster instead, note that ElastiCache cannot migrate slots containing items with serialized size larger than 256 MB.
5. Compression: gzip/zstd for text-heavy values at application layer

Cross-links

• Specific key in a hot prefix is oversized: big-key-hunter.md
• Per-shard imbalance (not prefix-based): slot-memory-imbalance-detection.md
• Eviction has started: troubleshooting.md Memory Pressure
• Alarm patterns: alarm-packs.md