The delayed job that
re-schedules itself.

A one-shot delayed job is a member in a sorted set scored by its fire-time. It runs once and is gone. A scheduler carries that one move forward: it keeps a registry of recurring schedules, one entry per registration, each scored by when it next runs. When an occurrence fires, the next run time is computed and the same entry's score is rewritten. The score is still a future timestamp, exactly as in the delayed queue — the new idea is that the entry is rewritten each cycle instead of consumed once.

Naming the cadence. There are two ways to name when next. A cron expression (0 9 * * *) names a wall-clock calendar position; a fixed interval (every_ms: 900000) names a gap. Both reduce to a single millisecond timestamp, which is the score the registry stores. EchoMQ.Repeat is the interval form: it carries an every_ms period and advances the score by it each cycle.

The registry. EchoMQ.Repeat declares two {q}-hashtagged keys, so a queue's repeat state lands on its own cluster slot: emq:{q}:repeat — a sorted set scored by the next-run millisecond, members the registration names — and emq:{q}:repeat:<name> — a hash carrying every_ms and the payload template. The registry carries only the next-run times; the period and template live in the companion hash.

The upsert (no duplicate on boot). A service that boots re-registers all its schedules. A naive add would push a second entry and the recurring job would fire twice. The @register script probes the record key first — if redis.call('EXISTS', KEYS[2]) == 1 then return 0. A present record returns 0 and writes nothing; register/6 answers {:ok, :exists}. Only a fresh name runs the HSET and the ZADD, answering {:ok, :registered}. One name, one record, one registry entry, across any number of boots.

Producing the next run (start-to-start). The registry holds only the next run. The cadence is EchoMQ.Pump's: each tick it reads the due registrations (ZRANGEBYSCORE emq:{q}:repeat -inf <now>), mints a fresh JOB id and enqueues each occurrence, then advances the score. advance/4 sets the new score to now_ms() + every_ms — start-to-start, measured from the release instant plus the period, not from a finish time. A slow occurrence does not push the cadence later.

Three dives, one per move on the single registry entry: how the next-run score is named, how it is kept unique across boots, and how it is rewritten each cycle.

A textbook delayed queue can already schedule one future run. A scheduler makes the run re-schedule itself. EchoMQ.Repeat keeps exactly one emq:{q}:repeat entry per registration name and makes the register idempotent with the EXISTS probe, so a restart re-registering the same name finds the record already present and changes nothing rather than spawning a duplicate. Registration is one inline Lua script; the guard is its first move, and only a fresh name runs the two writes:

KEYS[1] is emq:{q}:repeat (the registry sorted set), KEYS[2] is emq:{q}:repeat:<name> (the record hash), both gated onto the queue's slot. The score is the next-run millisecond; the member is the registration name. EchoMQ.Pump then sweeps the set each tick, minting a fresh branded JOB id per occurrence and advancing the score by every_ms start-to-start. The full cron parser, the timezone handling, and the scheduler-vs-delayed reconciliation across a worker pool belong to the EchoMQ course's Queue pillar.