The Elixir architecture

EchoMQ-Elixir ships no Application and no supervision tree of its own. The host application supervises the runtime's processes as children. The EchoMQ.Worker moduledoc shows the host wiring:

# in the HOST application's supervision tree
children = [
  {EchoMQ.RedisConnection, name: :redis, url: "redis://localhost:6379"},
  {EchoMQ.Worker,
    name: :my_worker, queue: "my_queue", connection: :redis,
    processor: &MyApp.Jobs.process/1, concurrency: 10}
]

There is no EchoMQ.Application to start; the worker and the connection pool are children the host owns. The in-tree EchoMQ.RedisConnection (use Supervisor) is the connection-pool internal — not a queue supervision tree. Pick a process below to read who owns it.

EchoMQ.Worker is a GenServer with @default_concurrency 1. On each fetch cycle it computes its spare capacity directly, then fetches that many jobs:

# worker.ex — the slot math, then a process per fetched job
available_slots = state.concurrency - map_size(state.active_jobs)

if available_slots > 0 do
  fetch_and_process_jobs(state, available_slots)
end

For every available slot it fetches a job and runs the processor in its own process via Task.async — one BEAM process per running job:

task =
  Task.async(fn ->
    run_processor(processor_fn, job, worker_pid, telemetry_mod, telemetry_metadata)
  end)
active_jobs = Map.put(state.active_jobs, job.id, {job, task.ref})

A crash in one job's process does not take down the worker or its siblings — the OTP isolation Elixir buys for free. Node, by contrast, runs concurrency on a single event loop, and Go runs goroutines; each runtime's concurrency model is its own L3.

EchoMQ.LockManager keeps every held lock fresh with one Process.send_after(:extend_locks) timer per worker — not one per job. When the worker picks a job up it calls LockManager.track_job(manager, job_id, token); when the timer fires, handle_info(:extend_locks, state) scans the tracked jobs and batch-renews the due ones in a single Scripts.extend_locks/5 call over extendLocks-1.lua (one stalled key, all ids and tokens packed into ARGV):

# lock_manager.ex — one timer, one batched script call
def handle_info(:extend_locks, state) do
  # scan tracked_jobs, select those past the half-window threshold,
  # then renew them all at once:
  Scripts.extend_locks(state.connection, state.keys, job_ids, tokens, state.lock_duration)
  Process.send_after(self(), :extend_locks, interval)   # re-arm the one timer
end

The renewal cost is flat — one timer, one round-trip — no matter how many jobs the worker holds. The full threshold-scan mechanics are in E2.03.1 · one timer, not N; the architectural point here is that lock renewal is one process, one timer, in the Elixir runtime.

EchoMQ.RedisConnection is a NimblePool-backed pool (use Supervisor) exposing command/3 and pipeline/3. Every script runs through EchoMQ.Scripts.execute_raw/4, which dispatches EVALSHA first and falls back to EVAL on a NOSCRIPT error:

# scripts.ex — EVALSHA, then reload + EVAL on NOSCRIPT
def execute_raw(conn, script, keys, args) do
  # num_keys = length(keys); encoded_args = pack(args)
  case RedisConnection.command(conn, ["EVALSHA", sha, num_keys | keys ++ encoded_args]) do
    {:error, %Redix.Error{message: "NOSCRIPT" <> _}} -> # reload, then EVAL
    result -> result
  end
end

EVALSHA sends the script's SHA, not its body, so a cached script costs one short round-trip. The same scripts run in Go (which caches via redis.NewScript) and in Node — the dispatch strategy above them is each runtime's own L3.

Every choice on this page — library-only, host-supervised, one BEAM process per job, one renewal timer per worker, a NimblePool connection, EVALSHA dispatch — is L3/L4, the Elixir runtime's own. The emq: keyspace it writes (L1) and the scripts it runs (moveToActive-11.lua, extendLocks-1.lua — L2) are frozen and shared. Go and Node drive the same wire their own way.

The worker fetch loop, the lock-renewal protocol, and the cached-script dispatch the reference runtime drives.