R4 · Time, Delay & Priority — chapter-closing dive
The road ahead.
One data structure — the sorted set — carries this whole chapter. The granular ladder takes one score reading at a time, and on the far side waits the system that runs them: the EchoMQ Queue.
Grounding: echo/apps/echo_mq · EchoMQ.Jobs · EchoMQ.Repeat · EchoMQ.Backoff
— the real surfaces each module cites, then the door into /echomq/queue and the durable
floor at /echo-persistence.
Static verdicts — R4.01 the schedule fence · R4.02 the repeat registry · R4.03 the score-0 pending order · R4.04 the backoff curve · R4.05 the leaderboard ZSET · R4.06 the workshop that schedules them.
The arc — one score reading at a time
echo_mq · the module ladderThe sorted set is the constant; the meaning of the score changes module to module. R4 walks the chapter one reading at a time, and each module is grounded in one real EchoMQ surface.
- R4.01 · The delayed queue — score a job by its fire-time and sweep the due head by
score. Grounded in
EchoMQ.Jobs.enqueue_at/6/enqueue_in/6andEchoMQ.Jobs.promote/3(the@promoteLua'sZRANGEBYSCORE -inf now). - R4.02 · Schedulers & repeatable jobs — recurring jobs via interval. Grounded in
EchoMQ.Repeat(the@registerupsert viaEXISTS) andEchoMQ.Metronome, which drives the beat. - R4.03 · Priority — serve one class ahead of another. EchoMQ serves the score-0
emq:{q}:pendingset in branded-id mint order, so theclaimscript'sZPOPMINreturns the oldest job. - R4.04 · Backoff & retry — exponential backoff with jitter, re-using the schedule
set. Grounded in
EchoMQ.Backoff.delay_ms/2(base × 2^(attempts-1), clamped, then optional jitter) andEchoMQ.Jobs.retry/7. - R4.05 · Leaderboards — real-time rankings on the same sorted-set machinery. Grounded in
codemojex's
Codemojex.Board, whichZADDs each player's best total tocm:<game>:boardand reads the top withZREVRANGE … WITHSCORES. - R4.06 · Workshop — schedule codemojex's notification and digest jobs over the schedule
and repeat sets (
Codemojex.NotificationWorkeroverEchoMQ.Jobs.enqueue_in/5).
The reliable queue learned its lifecycle in R3; here it learns a clock and an order. Read the arc as one queue gaining one sense — when, and in what order — from one sorted set read two ways.
The door beyond — the EchoMQ Queue
/echomq/queue · the engineR4 teaches the transferable sorted-set patterns. The engine that runs them is the subject of the dedicated
EchoMQ course — specifically the Queue pillar, which absorbs scheduling, the lifecycle
controls, and lanes. Where this course cites one excerpt as proof, that course teaches the subsystem that
runs it: the schedule fence in depth, the dynamic re-score (EchoMQ.Jobs.delay/6 moves an active
member back to the schedule set without consuming an attempt, token-fenced), and lanes with the metronome's
one-block-per-queue readiness fan-out.
The Queue, in depth
The schedule fence, the promote pump, the dynamic re-score EchoMQ.Jobs.delay/6, and lanes — the emq:{q}: queue protocol, taught in depth in the Queue pillar.
The durable floor
Where a scheduled or retried job survives a crash: ETS head, Valkey bus + L2, a durable page tier, then Tigris — the durability dial, with Oban as the comparison.
The patterns are the vocabulary; the EchoMQ Queue is the engine. Learn the score readings here, then go run them there.
The persistence floor — surviving a crash
echo_store/graft · the durability dialA scheduled or retried job lives on emq:{q}:schedule in Valkey memory. To survive a crash or a
replica swap it must reach a durable substrate. That is the persistence floor: ETS head →
the Valkey bus + warm L2 → a durable local page tier (the native EchoStore.Graft.* engine on
CubDB) → Tigris remote, behind a create-only commit fence. Durability is a dial — hold nothing,
checkpoint per window, or commit-per-record and replicate off-box — and the enqueue hot path touches only a
small, mostly-idle outbox beside the bus, never a database on the path of every dequeue.
The comparison is Oban, which keeps jobs in the same Postgres as the data so a job and a row commit in one transaction. EchoMQ separates the bus from the store and buys an in-memory hot path plus the dial; it gives up that one-transaction coupling. The durable substrate is the subject of the /echo-persistence course.
R4.01–R4.06 teach the sorted-set techniques applied: a job scored by fire-time, mint-ordered service, a recurring registry, a backoff reschedule. Each lands twice — the technique, then the one real EchoMQ excerpt that proves it.
The EchoMQ Queue applies them all under one engine — the schedule fence, the promote pump, the dynamic re-score, lanes and fairness — and beneath them the persistence floor that makes a scheduled job durable.
Notes on ValkeyThe schedule set lives in Valkey memory; the promote
pump reads the due head on the server clock (TIME) so a delay is measured on the same
clock the reaper reads, never the caller's — and the persistence floor is what carries that state past a
process restart — valkey.io/topics.
The patterns are the vocabulary; the EchoMQ Queue is the engine, and the persistence floor is the durable ground it stands on.
References
sources · relatedSources
- Valkey — Topics — the one structure this whole chapter reads two ways: a clock scored by fire-time and a mint-ordered queue scored 0.
- Redis — ZRANGEBYSCORE — the command that sweeps the due head of the schedule set, the engine of R4.01's promote step.
- Redis — ZADD — the single write behind the schedule set, the repeat set, and the leaderboard.
- llms.txt — The /llms.txt convention — the machine-readable map format both this course and the EchoMQ course publish.
Related in this course
- R4 · Time, Delay & Prioritythe chapter this dive closes
- R4 · The sorted set as a clockdive 1: one set read two ways
- R4 · Score as meaningdive 2: the score is the whole semantic axis
- The Queue — EchoMQthe engine, the schedule fence, and the promote pump, in depth
- R3 · The road aheadthe parallel orientation dive of the previous chapter