Worker — concurrency is not throughput.

The BEAM makes processes cheap. A deployment can run thousands of consumer processes for a few megabytes, and OTP supervises them for free, so the instinct is to add workers when a queue falls behind. But adding BEAM processes does not, on its own, raise throughput against Valkey.

The reason is the connector. A single owned socket carries one command at a time: requests go out and replies come back in order, on the wire. Ten processes sharing one connector do not get ten times the work done — they queue at the socket, and the wire serves them one round-trip at a time. Concurrency on the BEAM is not parallelism on the wire. The shared resource is the connection, and the unit of cost is the round-trip.

The claim loop is EchoMQ.Consumer. It holds a dedicated connector — a private lane, so a blocking verb cannot stall a shared one — and beats on a cadence: reap expired leases, promote due schedules, drain the ring with rotating claims, then park.

The handler is a function taking %{id:, payload:, attempts:, group:} and answering :ok or {:error, reason}. A returned error becomes a typed retry; a raising handler is caught and retried too, and the loop survives.

A naive worker loop polls: claim, and if the queue is empty, sleep a little and claim again. Polling spends round-trips on an idle queue and adds latency on a busy one. The consumer does neither. When the ring is drained it parks on the wake key with BLPOP until readiness arrives as a wake or the beat elapses:

BLPOP blocks the connection until something is pushed to the wake key or the timeout expires. An enqueue pushes a wake token, which unparks exactly the consumers waiting on it. A parked consumer costs the wire nothing — no round-trips spent waiting, and no polling delay when work arrives. The beat doubles as the cadence for the reap and promote sweeps, so an idle consumer still wakes periodically to do its housekeeping.

Because BLPOP holds the connection for the duration of the block, a blocking consumer needs its own connector lane — which is exactly why the consumer holds a dedicated connector and never shares one. A shared connector would have every other command on it wait behind the block.

Real parallelism against Valkey means more sockets. EchoMQ.Pool is a fixed pool of pipelined connectors with lock-free round-robin dispatch:

There is no checkout, no lock, no waiting for a free connection. A caller hits the next member by an atomic counter (:atomics.add_get) and the member’s own FIFO does the rest. One supervisor, N connectors, one dispatcher — the single connector, multiplied. Pool width is the number of round-trips that can be outstanding at once: it is the real parallelism, where the count of BEAM processes is only concurrency.

The consumer’s opt-in :metronome mode fans a pool’s readiness from one blocker: each consumer registers idle with the queue’s metronome, awaits a :claim_once poke, claims once, settles, and re-registers — one block per queue, the herd gone, readiness handed out fairly across the pool.

Every claim pops one job. claim/3 runs one ZPOPMIN against the pending set, mints a lease on the server clock, and returns one job — one job per claim, one round-trip per claim. The fetch is the throughput ceiling: a worker cannot go faster than its round-trips, and each round-trip carries one job.

The amortization is the batch claim. EchoMQ.Lanes.bclaim/3 is the count-variant of the same spine: it reads the pending depth, clamps k = min(requested, depth) so it never over-pops, reads one TIME for the whole batch so every served job is leased on the same deadline, then loops the per-job transitions and returns up to k jobs in one round-trip. The same fetch, amortized over k jobs.

So three knobs raise throughput, and they are independent. Pool width sets how many fetches are outstanding at once. Batch size sets how many jobs each fetch carries. The claim cadence (:beat_ms) sets how often a consumer reaches for work. None of them is the count of BEAM processes.

The technique is the consumer loop plus the pool plus the fetch. EchoMQ.Consumer owns the rhythm and parks on BLPOP so an idle worker is free; EchoMQ.Pool multiplies the sockets so many round-trips run at once; and the per-claim ZPOPMIN is the unit of throughput, amortized by EchoMQ.Lanes.bclaim/3 when one job per trip is the ceiling. The count of workers is concurrency; the pool width and the batch size are throughput.

A consumer makes the technique concrete. In codemojex — a Telegram emoji-guessing game on the same stack — Codemojex.Guesses.submit/3 enqueues each guess as a branded JOB on the player’s lane (emq:{cm}:…), and Codemojex.ScoreWorker is the scoring consumer: EchoMQ.Consumer drains the guess queue through Lanes.claim, the player id arriving as the lane group. During a busy event — many rooms guessing at once — the per-claim ZPOPMIN is the ceiling, and pool width plus the batch claim are what keep the scoring engine ahead of the field.

Wiring the claim loop into a production deployment — the pool sizing, the lease recovery, the metrics per queue — is the queue’s scaling layer, taught in the EchoMQ course rather than here.

Widen the pool and batch the claim when:

• A queue falls behind and adding consumer processes does not help — the bottleneck is the wire, not the BEAM, so the lever is more sockets (pool width), not more processes.
• The per-job work is small relative to the round-trip, so the fetch dominates and a batch claim (bclaim/3) amortizes it over several jobs.
• Many consumers compete on one queue and the thundering herd of wakes is a cost — the :metronome pool path fans readiness from one blocker.

Leave the defaults when:

• The queue keeps up at one connector and a modest beat — concurrency is not the constraint, and a wider pool buys nothing.
• The per-job handler work dwarfs the round-trip; then the fetch is not the ceiling, the handler is, and batching the claim changes little.
• A hard ceiling on the rate of work is the goal rather than throughput — that is the rate limiter, a per-window counter, not pool width.