The lifecycle, the
components & the runtimes

A reader who walked the → EchoMQ door from the reliable-queue pattern (R3) has met states-as-locations and the atomic-move thesis. A reader who finished E1 holds the immutable wire — the keys and the scripts. This chapter answers the next question: which eight states a job occupies, which script performs each transition between them, and how the lock keeps a job owned while a worker runs it. Read it when you need the mechanism in motion — reading a real queue's state, debugging a stalled job, or building on the core (every extension in E3–E8 stands on the lifecycle this chapter lays out).

The chapter holds one rule throughout — the Golden Rule: the state's keys (L1) and the transition's Lua script (L2) are immutable and shared across runtimes; the executor (L3) and the API (L4) vary. The interactive below reads the eight real states EchoMQ.Keys builds. Pick a state to see its Redis location and the script that moves a job into it.

Four teaching modules take the running library apart — the lifecycle, the components, the lock management, and the three runtimes — and a workshop runs a job through every state across two runtimes.

One transition makes the layering concrete. A worker picks up the next job: at L4 it calls a runtime API; at L3 the executor dispatches a script by SHA (EchoMQ.Scripts.move_to_active/4); at L2 the script moveToActive-11 runs atomically; at L1 it moves a job id from emq:{queue}:wait to emq:{queue}:active and sets the lock at emq:{queue}:{jobId}:lock with a UUID token and a PX TTL. The completion script moveToFinished-14 first verifies that token; a missing or mismatched lock returns -2 or -6 from the closed code set. L1 and L2 are byte-identical across runtimes; only L3 and L4 differ.

E2 closes Movement I. Movement II (E3–E8) then tracks the EMQ extension ladder, each chapter on a drafted rung, teaching the redis-patterns pattern, the rung's spec, and the as-built code together.