The road ahead

One sorted set carries the whole chapter. Each module takes one reading of the score in depth — and on the far side waits the engine that runs them all.

R4 reads one structure two ways: a clock and an order. The granular ladder R4.01 through R4.06 takes the score apart one reading at a time — fire-time, composite priority, the recurring registry, backoff, leaderboards, the workshop — and each is grounded in one real EchoMQ surface. Then the patterns hand off to the system that runs the scheduler: the living EchoMQ course. Walk the arc on the right, then open the door. The engine the patterns sit below is /elixir.

The arc R4.01–R4.06 The door map The door to EchoMQ References

The R4 arc · one sorted set, one score reading per module

The arc — one score reading at a time

R3 built a queue that is correct under a crash: a job moves from emq:{queue}:wait into emq:{queue}:active and on to completion, recoverable rather than lost. R4 keeps that floor and adds two senses to it — when a job runs, and in what order — from one structure, the sorted set, read two ways. The member is always the job id; only the score changes meaning. The granular ladder takes that score apart one reading at a time, and each module is grounded in one real EchoMQ surface.

R4.01 · The delayed queue scores a job by its fire-time and sweeps the due head by score. EchoMQ scores the :delayed ZSET as (timestamp + delay) × 0x1000, and promoteDelayedJobs runs a ZRANGEBYSCORE of the due head followed by ZREM to the wait list. The queue learns when.

R4.02 · Schedulers & repeatable jobs registers recurring jobs by cron or interval. EchoMQ keeps the :repeat ZSET, upserted with ZADD nextMillis customKey behind a ZSCORE check, so a reboot re-registers the schedule rather than duplicating it.

R4.03 · Priority with composite scores packs a tier and an arrival counter into one number. getPriorityScore computes priority × 0x100000000 + (INCR pc) % 0x100000000 — the tier in the high 32 bits, a monotonic arrival counter in the low 32, so jobs in a tier stay FIFO. The queue learns in what order.

R4.04 · Backoff & retry reschedules a failed job with exponential backoff and jitter. EchoMQ.Backoff.calculate/4 owns the delay (base × 2^(n-1), then jitter), and retryJob-11.lua re-adds the job onto the :delayed set with that delay.

R4.05 · Leaderboards turns the same ZSET machinery into real-time rankings. This module grounds in Portal progress rankings rather than EchoMQ, using the same ZADD / ZRANK / ZREVRANGE commands the rest of the chapter teaches.

R4.06 · Workshop puts the whole chapter to work: scheduling Portal's notification and digest jobs over the :delayed and :repeat sets on one real surface.

R4.01 — fire-time: The :delayed ZSET scored (ts+delay)×0x1000; promoteDelayedJobs sweeps the due head.
R4.02 — next-run: The :repeat ZSET upserted ZADD nextMillis customKey behind ZSCORE.
R4.03 — priority: getPriorityScore: priority×0x100000000 + pc, tier high, arrival low.
R4.04 — backoff: EchoMQ.Backoff.calculate/4 for the delay; retryJob-11.lua reschedules onto :delayed.
R4.05 — rankings: Portal progress rankings on the same ZADD/ZRANK/ZREVRANGE commands.
R4.06 — the workshop: Portal's notification and digest jobs over :delayed and :repeat.

Read the arc as one sorted set gaining one reading at a time: a fire-time, a recurring registry, a composite priority, a backoff reschedule, a ranking. The structure is the constant; the score is the chapter.

The door beyond — the living EchoMQ course

R4 teaches the transferable sorted-set patterns. The engine that runs them — the scheduler subsystem — is the subject of the dedicated EchoMQ course at /echomq. It is a living, agile-spec course, built in two movements. Movement I (E1–E2) teaches the as-built core library: the immutable wire protocol and data layer, then the lifecycle, components, and three runtimes. Movement II (E3–E8) is a living spine that tracks the EMQ extension ladder — emq.1 through emq.6 — rung by rung.

The patterns prove each score reading with one real excerpt and stop there. The scheduler subsystem owns the depth beyond the patterns: cron schedules across a timezone and a daylight-saving boundary; the busy-slot guard that holds a recurring job until its previous run finishes; the migration of legacy repeat keys onto the current registry; and parent-child flow scheduling, where a delayed or prioritized job gates a child flow. Pick a depth topic on the right to see which EchoMQ chapter owns it and which R4 pattern it extends.

# R4's EchoMQ doors (the content-grounded targets, per r4.progress.md)
  R4.02 schedulers     → E6   # timezone & DST, the busy-slot guard, legacy migration
  R4.03 priority       → E4   # intra-group priority & parent-child flow scheduling
  the scheduler depth  → E6 / E4 # lifecycle controls & groups own the engine

The course-level map pairs R4/R5 with E6/E7, but E7 is EchoCache, the near-cache — unrelated to time, delay, or priority. The honest, content-grounded doors are E6 · Lifecycle controls (the delay / promote / retry / TTL scheduler depth) and E4 · Groups (intra-group priority and the control plane). Pick a topic on the right to read what waits behind each door.

The scheduler-depth door map · each topic, the EchoMQ chapter that owns it, the R4 pattern it extends

A note on honesty. The EchoMQ course is designed — its spec system and TOC are authored — and the EMQ ladder is drafted (the emq.1–emq.6 specs exist). The served /echomq pages ship as the build lands. It is the living companion course, not a course produced all at once.

A door, not a depth

This is where the patterns hand off. Redis Patterns Applied has shown the sorted-set techniques — the fire-time score, the composite priority, the recurring registry, the backoff reschedule — and grounded each in how EchoMQ-in-Portal really uses it, one excerpt at a time. What it has deliberately not done is teach the scheduler subsystem in full: cron arithmetic across timezones and DST, the busy-slot guard, the legacy-repeatable migration, and parent-child flow scheduling. That depth is a course of its own.

the patterns

R4.01–R4.06 teach the sorted-set techniques applied. Each pattern lands twice — the technique and its trade-offs, then the one real EchoMQ excerpt that proves it. A catalog of judgement, grounded.

the system

The living EchoMQ course teaches the scheduler subsystem in depth and tracks the EMQ build — E1–E8 standing on emq.1–emq.6, the spec, and the as-built code together.

The patterns are the vocabulary; the EchoMQ scheduler is the engine. Learn the score readings here, then go run them there.

The forward door

Start building with the EchoMQ course

The polyglot scheduler taught end to end and tracked as it is built. R4 opens onto two of its chapters: lifecycle controls, which own the delay, promote, retry, and TTL depth, and groups, which own intra-group priority and the control plane. Begin at the course home, or step straight to R4's doors.

/echomq · the EchoMQ course E6 · Lifecycle controls E4 · Groups

Return to the chapter R4 · Time, Delay & Priority to review the time-and-priority family in one place, or carry on into the pattern chapters that follow.

References

Where the structure this chapter reads two ways is specified, the command that sweeps the delayed set, the protocol the whole arc builds on, the machine-readable map both courses publish, and the dives this orientation closes.

Sources

Redis — Sorted sets — the one structure this chapter reads two ways: a clock scored by fire-time and a priority ladder scored by a composite number.
Redis — ZRANGEBYSCORE — the command that sweeps the due head of the delayed set, the engine of R4.01's promote step.
BullMQ — the queue protocol whose scheduler EchoMQ ports across three runtimes, the source of the :delayed / :prioritized / :repeat score conventions.
llms.txt — The /llms.txt convention — the machine-readable map format both this course and the EchoMQ course publish for agents.

Related in this course

R4 · Time, Delay & Priority — the chapter this dive closes.
R4 · The sorted set as a clock — dive 1: one ZSET read two ways, a timer wheel and a priority ladder.
R4 · Score as meaning — dive 2: the score is the whole semantic axis — fire-time, composite priority, next-run-millis.
R3 · The road ahead — the parallel orientation dive that surveys the full course arc and the first EchoMQ doors.