The busy-poll cost

The naive wait is a spin. The worker pops the work list; an empty queue returns nil; the worker sleeps, then polls again.

# the polling loop — RPOP, sleep, retry
loop:
  job = RPOP wait              # nil when the queue is empty
  if job == nil:
    sleep(interval)            # burn the interval, then poll again
    continue
  process(job)                # a job arrived — run it

Every pass that returns nil is a wasted round-trip: a command sent to Redis and a nil sent back, for no work. On a queue that is empty most of the time, that is the steady state — the worker spends its life asking an empty queue whether it is still empty. A short interval makes that question cheap to ask but asks it constantly; the round-trips pile up while nothing happens.

A job rarely arrives exactly when the worker polls. It arrives somewhere in the gap between two polls, and waits the rest of the gap before the next poll picks it up. Over many arrivals, the wait averages about half the interval.

# a job arrives between two polls and waits for the next one
poll        poll        poll        poll
 |           |     ↑      |           |
 |<-- interval -->|       |           |
                  job arrives here, waits ~½ interval for the next poll

# average pickup latency over uniform arrivals
avg_latency  ≈  interval / 2

A 100 ms interval adds about 50 ms of average pickup latency on top of the work itself. The interval is a floor on responsiveness that no amount of worker speed removes: the job is already in Redis, but the worker will not look until its next scheduled poll.

The two costs pull against each other on the one dial. Shorten the interval to cut latency and the empty round-trips multiply; lengthen it to cut the round-trips and pickup latency grows. There is no value that is cheap on both axes, because polling pays for checking whether work exists separately from doing the work. Sweep the interval below and watch the latency bar fall as the round-trips bar climbs — no setting puts both low.

EchoMQ's worker does not run this loop on an idle queue. When no job is immediately available, it parks on a blocking fetch — EchoMQ.Worker.do_wait_for_job/3 runs BZPOPMIN emq:{queue}:marker timeout on a dedicated blocking connection — so it spends no round-trips while idle and picks a job up the instant the producer rings the marker. The polling loop above is what that blocking fetch replaces.

It is also what the Go port's empty-queue worker loop does: apps/echomq-go/pkg/echomq/worker_impl.go runs time.Sleep(100 * time.Millisecond) / time.Sleep(time.Second) when the queue is empty — a fixed-interval poll, the cross-runtime contrast to the marker block. The next two dives build the blocking primitive and the marker handshake that remove the cost.

// worker_impl.go — the Go worker loop polls with a fixed sleep (the contrast, NOT the marker block)
if err == redis.Nil {
    time.Sleep(100 * time.Millisecond)   // empty queue → wait a fixed interval, then poll again
    continue
}

The non-blocking pop the loop spins on, the blocking move that removes the interval, and the queue protocol that parks on the marker instead.