Rate limiting — a budget per window.

A rate limit needs three things: a counter, a window, and a limit. The window counter is the smallest arrangement that supplies all three with two commands. On each admitted request, increment the counter for the current window:

INCR returns the new value after the increment, so the count comes back in the same round trip that records it. If the returned count is 1, this request opened the window — set the window's lifetime so it expires when the window rolls:

From then on, every request compares the returned count against the configured limit. While the count is at or below the limit, the request is admitted. Once the count has reached the limit, the request is refused or deferred, and the back-off is exactly the time left on the key — the window does the resetting for you:

The window is the key's TTL. There is no separate timer, no scheduled reset, no clean-up sweep: when the key expires, the count is gone and the next INCR recreates it at 1. The counter is self-resetting because expiry is the reset — the same property the rest of this course leans on for sessions, locks, and idempotency keys.

The window counter is built from six commands, every one a documented Valkey operation. None is EchoMQ-specific; the pattern is plain Valkey, applied.

• INCR — atomically increment the counter and return the new value. One round trip records the admission and reports the count.
• PEXPIRE (or EXPIRE for second precision) — set the counter's lifetime to the window length, applied on the first increment so the window starts when its first request arrives.
• SET … PX — an alternative first-write that sets the value and the expiry together; used where the count is written rather than incremented.
• PTTL (or TTL) — read the time remaining on the key. When over budget, this is the precise back-off a caller waits before retrying.
• GET — read the current count without changing it; the read side of a limiter check.
• HGET — read the configured limit from a side hash (HGET emq:{orders}:meta max) so the cap is data, not a hard-coded constant.

The window counter is the simplest member of a family. Four algorithms trade simplicity against smoothness, and the right one depends on whether bursts are acceptable and how much state you will keep:

• Fixed window — one counter per fixed clock window (the shape in §1). Cheap and exact within a window, but bursty at the boundary: a caller can spend the full budget at the end of one window and again at the start of the next, admitting up to twice the limit across the seam.
• Sliding window — weight the previous window's count by the fraction still in view, or keep a sorted set of request timestamps trimmed to the last window. Smooths the boundary burst at the cost of more state.
• Token bucket — tokens accrue at a fixed rate up to a bucket size; each admitted request spends one. Permits bursts up to the bucket and sustains the refill rate — the shape for when short bursts are acceptable.
• Leaky bucket — a queue drained at a fixed rate, so output is constant regardless of how arrivals clump. Smooths the output rather than the input.

The fixed window is what EchoMQ's limiter implements, and the dives take each algorithm apart in turn: windows and the boundary burst, the two buckets and what they smooth, and why the counter must live in the store rather than in any worker.

EchoMQ exposes the read side of a fixed-window limiter as a shipped surface. EchoMQ.Metrics.get_rate_limit_ttl/3 reads two keys — emq:{q}:limiter and emq:{q}:meta — and answers the remaining window in milliseconds, 0 when the queue is not over budget. Its inline Lua is the fixed-window read, exactly the §1 shape:

The script maps one to one onto the pattern: KEYS[1] is emq:{q}:limiter, the counter; the limit is read from the emq:{q}:meta hash field max (or passed directly); when the counter has reached max and the window still has time, the remaining PTTL is returned as the over-budget back-off. EchoMQ.Metrics.get_global_rate_limit/2 reads that configured cap on its own (HGET emq:{q}:meta max, 0 when unconfigured). When a limit is hit, EchoMQ.Meter.rate_limit_hit/2 emits [:emq, :rate_limit, :hit] with %{delay: delay} — the telemetry receipt that work was held back, at zero cost when :telemetry is not loaded.

The counter and its window are the shipped primitive. The enforcement loop — incrementing the counter on each claim and sending an over-budget job back to wait — is the scaling layer, taught in the EchoMQ course rather than here. The read surface above answers how much budget is left; wiring that into the dequeue point is the deeper protocol work the door below covers.

Reach for a rate limiter when:

• A shared service where one caller, tenant, or runaway loop could consume capacity others need.
• An external dependency with its own published limits you must stay under — a third-party API, an outbound message channel.
• Fair access across tenants on one cluster, where each tenant gets a budget per window.
• Protecting a backend from a thundering herd by capping admitted work to what the backend can absorb.

Avoid it when:

• The constraint is concurrency, not rate — a ceiling on simultaneous in-flight work is a different primitive (a count of active leases, EchoMQ's glimit/gactive per-lane ceiling), not a per-window count.
• Exact fairness down to the request matters more than throughput — a fixed window's boundary burst admits up to twice the limit across the seam; reach for a sliding window or a token bucket instead.
• The limited resource is purely local to one process and never shared — an in-process guard is lighter than a round trip to the store.
• The cost of a refused request (a dropped event, a lost signal) is higher than the cost of letting it through — back-pressure or a queue may serve better than a hard refusal.