Core Data Structures

0.81% is a standard deviation, not a bound: at 50 million uniques a typical estimate is off by ~400k, and a couple of percent happens. 12 KB is the dense form of 16384 six-bit registers; small keys use a compact sparse encoding and convert to dense once they exceed hll-sparse-max-bytes, irreversibly.

With LPOP the job is gone the moment it is delivered, so a crash loses it. Instead use BLMOVE queue processing:<worker> LEFT RIGHT: it atomically pops and appends to a per-worker processing list, so the job stays visible. Remove it with LREM after success. You must still write the reaper for orphaned entries and make handlers idempotent.

HyperLogLog serves only the sliced counts, via one key per slice plus PFMERGE rollups. Membership and intersection are impossible with it: no per-element test, no PFINTERSECT, and inclusion-exclusion is numerically useless. Serve those with Sets, bitmaps over dense user IDs, or an offline store, and budget ~12 KB per dense slice key.

Model one Set per tag holding item ids, plus a reverse Set per item for maintenance. AND is SINTER, OR is SUNION, exclusion SDIFF. It degrades when every selected tag is huge: the work happens in one blocking command. Mitigate with selective-tag ordering, SINTERCARD LIMIT, SINTERSTORE into short-TTL result keys, and precomputed hot combinations.

Exact rank and top-N stay cheap — both are O(log N). Deep pagination by index is not: cost grows with the offset. Memory and single-key hotness are the real ceilings. Paginate by score cursor, serve reads from replicas, shard into cohort boards, and approximate global rank with score-bucket counters.

GEOSEARCH unifies GEORADIUS and GEORADIUSBYMEMBER (FROMLONLAT or FROMMEMBER) and adds rectangle search with BYBOX. GEORADIUS had an optional STORE clause, so Redis classified it as a write command and replicas refused it — hence the separate GEORADIUS_RO. GEOSEARCH is read-only; GEOSEARCHSTORE is the writing variant.

Coordinates are quantised to 26 bits per axis, so GEOPOS comes back within roughly a metre of what you wrote, never bit-identical. GEODIST is a great-circle distance on a sphere — a straight line, no roads, no altitude, with sub-percent error. Latitude is limited to about ±85.05°, so the poles cannot be stored.

They only make sense when every member has the same score — then ordering is purely by member bytes and the sorted set becomes an ordered string index. Intervals need a prefix: [ inclusive, ( exclusive, - minimum, + maximum. Used for prefix search, autocomplete and cursor pagination.

BITFIELD packs many small integers into one string, addressed by bit offset and width (u1..u63, i1..i64). It runs GET/SET/INCRBY operations atomically in one command. OVERFLOW chooses what happens on wrap: WRAP wraps around, SAT clamps at the limit, FAIL returns nil and skips the write.

BITOP AND/OR/XOR/NOT combines bitmaps into a destination key, then BITCOUNT gives the answer: AND of seven day keys counts users active every day. It is O(total bytes) and writes a full-size result key, so batch it off the hot path, give the result a TTL, and mind memory.

It trades RAM for CPU on the single command thread: listpack access is a linear scan and writes may rewrite the whole blob, so 4096-entry values raise tail latency for every access. Evaluate per workload with measured memory and p99, set per-instance rather than fleet-wide, and prefer a moderate bump plus a hard cap on element size.

One key lives in one hash slot on one shard, so a single global index pins every position write and every query to one core, and dense-area queries scan huge candidate sets. Partition by region (geo:{city}) or geohash-prefix cell, fan out to neighbouring cells client-side, and sweep stale members with ZREM since geo members have no TTL.