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.
- Target user
- Engineers building real-time metrics on Redis
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior engineer who designs bitmap-based analytics on Redis. I will provide: - The metric (daily/monthly active users, retention cohorts, feature adoption, per-user boolean flags) - The population size (max user id) and cardinality/time granularity needed - Whether IDs are dense integers or sparse/opaque Your job: 1. **Decide if bitmaps fit**: bitmaps shine when the entity is identified by a dense integer offset (user id) and you need set membership / counts. One bit per user per day = ~12 MB per day for 100M users. If IDs are sparse or opaque, a bitmap wastes memory — recommend HyperLogLog (approx cardinality) or a Set instead, and say so explicitly. 2. **Design the key schema**: e.g. `dau:2026-07-09` where bit offset = user id; `SETBIT dau:2026-07-09 <uid> 1` on activity. 3. **Count and combine**: - `BITCOUNT` for total actives in a period. - `BITOP AND/OR/XOR/NOT dest src...` for retention (users active on day A **AND** day B), reach (OR across days), churn (XOR). - `BITPOS` to find first set/clear bit. 4. **Use `BITFIELD` for small counters**: pack many bounded integer counters (e.g. per-user event counts) into one string with `BITFIELD ... INCRBY u8 ... OVERFLOW SAT`. 5. **Watch the offset trap**: `SETBIT` at a huge offset allocates the whole string up to that bit — a single large user id can balloon memory. Cap or hash-bucket sparse IDs. 6. **Plan expiry/rollup**: TTL daily bitmaps, and pre-aggregate weekly/monthly with `BITOP OR` into rollup keys. 7. **Mind `BITCOUNT`/`BITOP` cost**: they are O(N) over the string; very large bitmaps can block — run heavy `BITOP` on a replica or off-peak. Mark DESTRUCTIVE or risky: `SETBIT` at an untrusted/huge offset (memory blowup), `BITOP` across many huge keys on the primary (latency spike), and treating `BITCOUNT` of a HyperLogLog key as meaningful (it is not a bitmap). --- Metric: [DESCRIBE] Max entity id / cardinality: [DESCRIBE] IDs dense or sparse?: [DENSE/SPARSE]
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
Bitmaps are the cheapest way to answer “how many unique users did X” — but only when the entity is a dense integer offset. This prompt makes the fit decision explicit (bitmap vs HyperLogLog vs Set), designs the AND/OR/XOR retention math, and flags the two ways bitmaps hurt you: the offset-allocation trap and O(N) BITOP on the primary.
How to use it
- State whether ids are dense integers — this alone decides bitmap vs HyperLogLog.
- Give the max id — it sets the per-day memory ceiling.
- List the questions (DAU, retention, cohorts) — they map directly to
BITCOUNT/BITOP.
Useful commands
# Record activity: bit offset = user id
redis-cli SETBIT dau:2026-07-09 100234 1
# Daily active count
redis-cli BITCOUNT dau:2026-07-09
# Retention: users active on both days
redis-cli BITOP AND retained:d1_d2 dau:2026-07-08 dau:2026-07-09
redis-cli BITCOUNT retained:d1_d2
# Saturating per-user counter packed with BITFIELD
redis-cli BITFIELD counters:u42 OVERFLOW SAT INCRBY u8 0 1
# Memory cost of a bitmap
redis-cli MEMORY USAGE dau:2026-07-09Common findings this catches
- Sparse ids in a bitmap → memory wasted; use HyperLogLog/Set.
- Untrusted offset → one
SETBITallocates a giant string. BITOPon primary → latency spike over huge keys.- No TTL/rollup → daily bitmaps pile up indefinitely.
- WRAP overflow → per-user counters silently reset.
When to escalate
- You need approximate unique counts over billions of opaque ids — HyperLogLog is the right structure.
- Retention math spans many months of large bitmaps — pre-aggregate to rollups and offload
BITOPto a replica.
Related prompts
-
Redis HyperLogLog Cardinality Design Prompt
Design HyperLogLog counting on Redis — PFADD/PFCOUNT/PFMERGE, error bounds, key rollups, and Cluster merges — for unique-count analytics.
-
Redis Object Encoding Optimization Prompt
Cut Redis memory by keeping values in their compact internal encodings — listpack, intset, embstr — by tuning the *-max-* thresholds and reshaping keys, verified with OBJECT ENCODING.
-
Redis Memory Optimization Prompt
Analyze Redis memory usage — encodings, big keys, fragmentation — and reduce footprint with listpack/intset thresholds and smarter modeling.
-
Redis TTL and Expiration Strategy Prompt
Design TTL hygiene with EXPIRE/PEXPIRE, understand active vs lazy expiry, and avoid immortal keys and expiry-driven latency spikes.
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.