Skip to main content
skill CX Codex

redis-clustering — Claude Code skill: hash tags, replica reads

Teaches the agent how to place keys across Redis Cluster slots and move read traffic off primaries. Useful when a CROSSSLOT error shows up or you are designing keys up front.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add redis/agent-skills --skill redis-clustering -a claude-code
Open on GitHub

What redis-clustering does

The skill covers the two things that trip up most people turning on cluster mode. First, the CROSSSLOT error: any command touching several keys (MGET, SDIFF, transactions, pipelines, Lua scripts) needs all of them in one slot. A hash tag fixes that, because only the part between { and } is hashed for slot assignment.

Scope the tag to the entity — {user:1001}, not a bare {1001}, or unrelated namespaces like purchase:{1001} and employee:{1001} collide on the same slot. Tag only the keys that actually need multi-key operations. Tag everything and you get hotspots, which defeats sharding. Renaming keys in production hurts, so plan tags before launch.

The second part is replica reads. In RedisCluster you turn them on with read_from_replicas=True: writes go to the primary, and a get may be served by a replica. For plain primary/replica setups the skill points two clients at the right hosts instead. The cost is consistency, since replicas are eventually consistent. Don't read your own writes from a replica, and keep anything needing strict freshness — balances, idempotency state — on the primary. Caches, analytics, dashboards and recommendation feeds are fine.

What it helps with

  • place keys so multi-key operations stop failing
  • debug a CROSSSLOT error on MGET, SDIFF or a pipeline
  • build a transaction or Lua script that touches several keys in a cluster
  • take read load off the primary by routing it to replicas
  • decide where hash tags help and where they create hotspots

Example prompts for the agent

  • I'm getting CROSSSLOT on MGET for user:1001:profile and user:1001:settings — help me redesign the keys
  • Design Redis Cluster keys for a user's cart and orders so transactions work
  • Set up replica reads in RedisCluster for a dashboard, keep writes on the primary

How to install redis-clustering

1Skills CLI (Vercel)

npx skills add redis/agent-skills --skill redis-clustering -a claude-code

2Manually: put the files in place

~/.claude/skills/redis-clustering/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/redis-clustering/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about redis-clustering

How do I install redis-clustering in Claude?

Run npx skills add redis/agent-skills --skill redis-clustering -a claude-code. The skill lands at ~/.claude/skills/redis-clustering/SKILL.md.

What does redis-clustering do?

It gives the agent rules for hash tags in multi-key operations and for reading from replicas. That helps both when debugging CROSSSLOT and when designing keys.

Can I read everything from replicas?

No. Replicas are eventually consistent, so don't read your own writes or freshness-critical data from them. Caches, analytics and dashboards are the right fit.

Source text

SKILL.md · MIT
---
name: redis-clustering
description: Redis Cluster and replication guidance covering hash tags for multi-key operations, avoiding CROSSSLOT errors, and reading from replicas to scale read-heavy workloads. Use when designing keys for a sharded Redis Cluster, debugging CROSSSLOT errors on MGET / SDIFF / pipelines, configuring a multi-key transaction in a cluster, or routing reads to replicas for caches, analytics, or dashboards.
license: MIT
metadata:
  author: Redis, Inc.
  version: "0.1.0"
---

# Redis Clustering

Guidance for designing keys and routing reads in a sharded Redis Cluster (and in standalone primary/replica replication). Covers the two failure modes that bite most new cluster users: `CROSSSLOT` errors on multi-key operations, and overloading primaries with read traffic.

## When to apply

- Designing keys for a Redis Cluster deployment.
- Debugging a `CROSSSLOT` error on `MGET`, `SDIFF`, transactions, or pipelines.
- Implementing transactions / Lua scripts that touch multiple keys.
- Scaling out read traffic without adding shards.

## 1. Hash tags for multi-key operations

Redis Cluster distributes keys across 16,384 slots by hashing the key name. Any command that touches **multiple keys** (`MGET`, `SDIFF`, `SUNIONSTORE`, transactions, pipelines, Lua scripts with multiple `KEYS[]`) requires all keys to live on the **same slot** — otherwise the server returns a `CROSSSLOT` error.

Hash tags force this: the part between `{` and `}` is the only thing hashed for slot assignment, so two keys sharing a hash tag always land together.

```python
# Same slot — multi-key ops work
redis.set("{user:1001}:profile",  "...")
redis.set("{user:1001}:settings", "...")
redis.lmove("{user:1001}:pending", "{user:1001}:processed", "LEFT", "RIGHT")
```

```python
# Different keys, no hash tag — CROSSSLOT on multi-key commands in cluster mode
redis.set("user:1001:profile",  "...")
redis.set("user:1001:settings", "...")
pipe = redis.pipeline()
pipe.get("user:1001:profile")
pipe.get("user:1001:settings")
pipe.execute()  # CROSSSLOT error in cluster
```

Rules of thumb:

- **Use a tag scoped to the meaningful entity**, e.g. `{user:1001}`. Avoid bare `{1001}` — unrelated namespaces (`purchase:{1001}`, `employee:{1001}`) would all collide on the same slot.
- **Only tag where you actually need multi-key ops.** Tagging everything creates hotspots and defeats the point of sharding.
- A single-key command on a hash-tagged key works fine, so adding tags later is incremental — but renaming keys in production is painful, so plan tagging up front for entities you'll group.

See [references/hash-tags.md](references/hash-tags.md).

## 2. Read replicas for read-heavy workloads

If reads dominate writes, route them to replicas to free primary capacity. Works both in Redis Cluster (each shard has 1+ replica) and in standalone primary/replica replication.

```python
# Redis Cluster: enable replica reads on the client
from redis.cluster import RedisCluster

rc = RedisCluster(host="localhost", port=6379, read_from_replicas=True)
rc.set("key", "value")     # → primary
value = rc.get("key")       # → may be served by a replica
```

For non-cluster setups, point two clients at the right nodes:

```python
primary = Redis(host="primary-host", port=6379)
replica = Redis(host="replica-host", port=6379)
primary.set("key", "value")
value = replica.get("key")
```

The trade-off is consistency: **replicas are eventually consistent**. Don't read your own writes from a replica; don't use replica reads for anything that requires strict freshness (financial balances, idempotency state). Good fits: cache layers, analytics, dashboards, recommendation feeds.

See [references/read-replicas.md](references/read-replicas.md).

## References

- [Redis Cluster spec — hash tags](https://redis.io/docs/latest/operate/oss_and_stack/reference/cluster-spec/#hash-tags)
- [Redis: multi-key operations in cluster](https://redis.io/docs/latest/operate/rs/databases/durability-ha/clustering/#multikey-operations)
- [Redis: Replication](https://redis.io/docs/latest/operate/oss_and_stack/management/replication/)

© Redis, Inc. · MIT · redis/agent-skills

Similar skills

All skills for Data and databases →

From the same set8

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor