Priority with composite scores

A Redis sorted set keeps its members in order by a numeric score. Read it low-to-high and the smallest score is at the head. When two members carry the same score, the set falls back to lexicographic order of the member to break the tie. The ordering is two-level by construction: the score first, the member second.

ZADD scores 100 "alice" 200 "bob" 150 "charlie"
ZRANGE scores 0 -1
# Returns: alice, charlie, bob — sorted by score

The score is the whole ordering axis. Choose what number goes in it and the set's order becomes whatever that number means. The interactive below loads a fixed set of six prioritized jobs, computes each composite score, sorts ascending, and names the job a ZPOPMIN would return next.

The composite-key pattern encodes several fields into one ordering key so a single sorted set answers a hierarchical query. In its lexicographic form the fields go into the member string, read by ZRANGEBYLEX.

ZADD events 0 "user:100:1706648400:login"
ZADD events 0 "user:100:1706648500:click"
ZRANGEBYLEX events [user:100: (user:100:\xff   # all user:100 events, ordered by timestamp

The second encoding puts the high-order field in the score and the low in the member. Members sort by score first, then lexicographically within an equal score, so the score can carry a category or a tier while the member carries the order within it.

ZADD hybrid 1 "a:first" 1 "a:second" 2 "b:first" 2 "b:second"
ZRANGE hybrid 0 -1
# Returns: a:first, a:second, b:first, b:second — bucket by score, order within

Bucketing falls out: group items by score (a category, a priority tier) and order within each bucket. A priority queue is the same composite key, encoded entirely in the score — both the tier and the position within it.

A priority queue packs both fields into the score. The score is priority × 0x100000000 + counter. 0x100000000 is 232, so multiplying the priority by it shifts the tier into the high thirty-two bits; the arrival counter sits in the low thirty-two bits. One IEEE double carries both fields exactly — a double holds fifty-three bits of integer precision, ample for small priorities and counters.

-- getPriorityScore.lua (included by addPrioritizedJob-9) — real
local prioCounter = rcall("INCR", priorityCounterKey)
return priority * 0x100000000 + prioCounter % 0x100000000
-- high 32 bits = the priority tier · low 32 bits = the arrival counter

The counter is the value of INCR pc — an atomic increment of the priority-counter key, taken at the moment the job is added. Every prioritized add reads a fresh, monotonically rising counter, so two jobs in the same tier get two different low-bit fields: the earlier add gets the smaller counter. A lower priority number means higher precedence — priority 1 produces a smaller high-bit field than priority 2, so its composite score is smaller, and the set keeps it nearer the head.

Two jobs of the same priority share the same high thirty-two bits. The tie is broken by the low thirty-two bits — the arrival counter. Because INCR pc rises by one per add, the first job to arrive in a tier carries the smaller counter and so the smaller composite score. The set orders same-tier jobs by arrival, head first: strict FIFO within the tier, with no second structure and no scan.

Without the counter, a score of priority alone would tie every job in a tier, and the set would fall back to member order — the job id — which is not arrival order. The counter is what breaks the tie deterministically and in the order jobs arrived. The second dive takes this apart in full.

A worker takes the next job with ZPOPMIN — pop the member with the smallest score. The smallest composite score is the highest-priority tier (the smallest priority number) and, within that tier, the earliest arrival (the smallest counter). One command returns the right job and removes it atomically.

ZPOPMIN emq:{queue}:prioritized
# Returns the smallest-score member: highest-priority tier, earliest arrival — and removes it

In EchoMQ the popped job id is then pushed onto the active list with LPUSH. ZPOPMIN is the reason a lower priority number wins: the formula makes a higher-precedence job a smaller number, and ZPOPMIN always returns the smallest first. The third dive walks the real consume in moveToActive-11.lua.

A single composite score earns its place when the ordering is fully numeric and one pop must return the right job: a priority queue, a numeric ranking, any case where the high-order field and the tie-breaker are both numbers. One sorted set then replaces a per-tier structure plus a separate FIFO, and the consume is one ZPOPMIN.

Reach for the member-packed lexicographic key instead when the fields are strings and the read is a prefix or range query — autocomplete, hierarchical composite keys, time-series with string ids — where ZRANGEBYLEX over the member is the natural read. Score-packing and member-packing are the same composite-key idea; the choice is whether the read is a numeric pop or a lexicographic range.

Each dive takes one layer of the composite priority score, building on the source spine and adding the EchoMQ grounding on top: the number that packs both fields, the counter that orders within a tier, and the pop that reads them. Read them in order — the packing first, the FIFO second, the pop third.

The Redis commands behind the composite priority score — the sorted set as a priority ladder, the score, the atomic counter, the smallest-score pop — the lexicographic contrast, and where the groups that prioritize within it are taught.