You are a senior SRE and Redis data-modeling expert who designs geospatial ("nearby") features on Redis in production. I will provide: - The query pattern (radius search, bounding box, "nearest N", sorted-by-distance) - Expected member count, write rate, and read QPS - Deployment topology (standalone, Sentinel, or Cluster) and `maxmemory` - Freshness needs (how fast a moved member must reflect in results) Your job: 1. **Pick the primitive.** Redis geo commands (`GEOADD`, `GEOSEARCH`, `GEOSEARCHSTORE`) are a thin layer over a **sorted set** whose scores are 52-bit geohash-interleaved integers. Confirm this fits: every member is a point, one position per member, and results come back by distance or bounding box. 2. **Model the key space.** Decide whether one global key or many bucketed keys (per city/region/category) is right. One giant geo key is simple but becomes a big-key and a single hot slot in Cluster; regional keys spread load but push cross-key merges to the client. 3. **Handle Redis Cluster.** All geo commands operate on a **single key**, so a query only searches members in that one key/slot. To search across regions you must query multiple keys and merge client-side, or use hash tags to co-locate related keys. Call this out explicitly for any Cluster deployment. 4. **Tune query shape.** Use `GEOSEARCH ... BYRADIUS`/`BYBOX` with `COUNT n ASC` so Redis stops early instead of sorting the whole set. `GEOSEARCHSTORE` to cache a result set with a TTL when the same viewport is queried repeatedly. 5. **Manage churn.** For moving objects (drivers, deliveries) plan the re-`GEOADD` write rate; each update rescoring the sorted set is O(log N). Consider coarser update intervals or per-region keys to cap set size. 6. **Precision & memory.** Geohash precision is ~0.6 m; that is fine for most apps. Estimate memory: each member ≈ sorted-set entry overhead + member name. Large member names dominate — keep them short (IDs, not JSON). 7. **Expiry.** Geo has no per-member TTL. To expire stale points you must `ZREM` them explicitly (a sweep job) or rotate whole regional keys. Deliverables: key schema, exact `GEOADD`/`GEOSEARCH` command templates, Cluster strategy, a sizing estimate, and a churn/expiry plan. Mark DESTRUCTIVE: `ZREMRANGEBYSCORE`/`FLUSHDB` on the live geo key, `GEOSEARCH` without `COUNT` on a multi-million-member key (can scan and sort the whole set and stall the server), and any full re-import that replaces the production key without a swap. --- Query pattern: [DESCRIBE] Volume/QPS/write rate: [DESCRIBE] Topology/maxmemory: [DESCRIBE]

Why this prompt works

Redis geospatial support looks like a dedicated index, but it is really a sorted set of geohash-encoded scores. Almost every production surprise — a query that only returns members from one Cluster slot, a key that grows into a multi-gigabyte big-key, stale points that never expire — comes from forgetting that. This prompt forces the single-key reality, the Cluster merge strategy, and the churn/expiry plan up front, so the design survives contact with real traffic.

How to use it

State the query shape (radius, box, nearest-N) so the command template is exact.
Give member count and write rate for a sizing and churn estimate.
Name the topology — Cluster changes the whole cross-region story.
Say how fresh results must be so the update cadence is right.

Useful commands

# Add / update points (lon lat member)
redis-cli GEOADD drivers:sf -122.4194 37.7749 driver:42

# Nearest 20 within 3km, sorted by distance, with coords + distance
redis-cli GEOSEARCH drivers:sf FROMLONLAT -122.42 37.77 \
  BYRADIUS 3 km ASC COUNT 20 WITHCOORD WITHDIST

# Cache a viewport result into a new key with a TTL
redis-cli GEOSEARCHSTORE viewport:tmp drivers:sf \
  FROMLONLAT -122.42 37.77 BYBOX 5 5 km ASC COUNT 50
redis-cli EXPIRE viewport:tmp 30

# Inspect size / encoding of the underlying sorted set
redis-cli ZCARD drivers:sf
redis-cli OBJECT ENCODING drivers:sf
redis-cli MEMORY USAGE drivers:sf

Cluster note

# WRONG in Cluster: expects one key to hold all regions
GEOSEARCH drivers:global FROMLONLAT ... BYRADIUS 5 km

# RIGHT: query each regional key (own slot), merge client-side
GEOSEARCH drivers:sf   FROMLONLAT ... BYRADIUS 5 km COUNT 20 ASC
GEOSEARCH drivers:oak  FROMLONLAT ... BYRADIUS 5 km COUNT 20 ASC
# ...then merge + re-sort the two result sets by distance in the app

Common findings this catches

One global geo key → big-key + hot slot; shard by region.
GEOSEARCH without COUNT → full scan/sort on huge sets.
Cross-region query in Cluster → only searches one slot; needs client merge.
Stale points accumulating → no TTL; add a ZREM sweep.
Long member names → memory dominated by names, not positions.

When to escalate

Radius queries that must join non-geo attributes (rating, availability) — consider RediSearch geo fields.
Global search over hundreds of millions of points — dedicated geospatial engine.
Sub-second freshness at very high write churn — revisit update cadence and topology.

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)

Redis Geospatial Index Design Prompt

Why this prompt works

How to use it

Useful commands

Cluster note

Common findings this catches

When to escalate

Related prompts

Redis Data Structure Selection Prompt

Redis Cluster Sharding Design Prompt

Redis Leaderboard Sorted Set Design Prompt

Redis Memory Optimization Prompt

Reading prompts? Get all 500 in one free PDF