jonnify·redis /redis-patterns/time-delay-priority/the-road-ahead

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.

The arc — one score reading at a time. Hover or select a step to read its reading of the score and the real EchoMQ surface that grounds it.
R4.01delayedqueue R4.02schedulers R4.03priority R4.04backoff& retry R4.05leader-boards R4.06workshop
readout · Hover or select a module to read its score reading and the real EchoMQ surface that grounds it.

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.

§1

The arc — one score reading at a time

echo_mq · the module ladder

The 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/6 and EchoMQ.Jobs.promote/3 (the @promote Lua's ZRANGEBYSCORE -inf now).
  • R4.02 · Schedulers & repeatable jobs — recurring jobs via interval. Grounded in EchoMQ.Repeat (the @register upsert via EXISTS) and EchoMQ.Metronome, which drives the beat.
  • R4.03 · Priority — serve one class ahead of another. EchoMQ serves the score-0 emq:{q}:pending set in branded-id mint order, so the claim script's ZPOPMIN returns 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) and EchoMQ.Jobs.retry/7.
  • R4.05 · Leaderboards — real-time rankings on the same sorted-set machinery. Grounded in codemojex's Codemojex.Board, which ZADDs each player's best total to cm:<game>:board and reads the top with ZREVRANGE … WITHSCORES.
  • R4.06 · Workshop — schedule codemojex's notification and digest jobs over the schedule and repeat sets (Codemojex.NotificationWorker over EchoMQ.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.

§2

The door beyond — the EchoMQ Queue

/echomq/queue · the engine

R4 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 two doors. Hover or select a destination to read what it owns beyond the patterns.
readout · Select a door to read what it owns beyond R4's transferable patterns.

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

§3

The persistence floor — surviving a crash

echo_store/graft · the durability dial

A 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.

the patterns

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 system

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.

§4

References

sources · related

Sources

  • 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