Priority Messaging: How Urgent Tasks Cut Ahead Without Starving Regular Tasks

1. The Problem: Verification Codes Stuck Behind Marketing SMS

When verification codes get blocked by a batch of marketing SMS, the first question is why these two task types share a single long queue. Assigning the highest priority to verification codes solves part of the problem, but if verification codes keep flooding in, ordinary tasks may never get processed. Soon payment notifications and logistics reminders also demand the highest priority, leading to a configuration table with eight levels while production uses only one.

Priority allocation addresses how limited processing capacity is distributed: urgent tasks wait less, but ordinary tasks must also make progress.

The architecture uses tiered access with guaranteed capacity per level, shared capacity allocated by weight, and wait time including message dwell in the MQ.

2. Cutting in Line Does Not Mean Preempting Running Tasks

A message may still be in the broker, in the client buffer, or already occupying a worker thread. The broker prioritizes delivery of new urgent messages but will not interrupt an already executing ordinary task.

Therefore, prefetch, buffer sizes, and thread pool queues must be limited. If the consumer pre-fetches tens of thousands of ordinary tasks, an arriving urgent message still waits in the application. RabbitMQ's consumer prefetch setting alone is insufficient; verification codes and marketing SMS sharing a saturated channel quota will still block. What needs a guaranteed floor is capacity across the entire execution chain.

3. Different MQs' "Priority" Mechanisms Must Not Be Conflated

RocketMQ 5.4.0 : Native priority topic, POP consumption. Key boundary: Does not support Pull priority consumption; no cross-broker global priority guarantee.

RabbitMQ Classic : Declare x-max-priority. Key boundary: Current 4.3 docs describe level round-robin; delivery guarantee == completion deadline.

RabbitMQ 4.3 Quorum : Auto-enables strict 0–31 priority. Key boundary: Does not use x-max-priority; low levels may starve.

Kafka Regular Consumption : Tiered topics, independent resources, or application scheduling. Key boundary: Header carries priority but does not reorder partition logs.

Pulsar : Tiered topics or application scheduling. Key boundary: Shared consumer priority, not message priority.

RocketMQ 5.4.0 has released RIP-80; it can no longer be said generically that it lacks priority support. Integration still requires verifying broker, proxy, client, and consumption mode against release notes and design boundaries.

RabbitMQ scheduling rules differ across versions and queue types; upgrade must re-benchmark ordinary task wait times for both Classic and Quorum queues.

Kafka's consumption flow control and Pulsar's consumer priority cannot substitute for message-level scheduling (Kafka API, Pulsar API).

4. Preventing Ordinary Task Starvation

Weighted Round-Robin. For example, urgent, normal, and background tasks get pull opportunities in a 6:3:1 ratio; an empty level is skipped. The ratio is illustrative; the key is every level gets a share so that "urgent never empty → normal never seen" cannot happen.

Pull count ≠ compute allocation. A transcoding task and a status update differ vastly in duration, so they should use separate worker pools or be budgeted by cost.

Resource Reservation. Reserve dedicated execution slots and downstream quotas for ordinary tasks; the rest is shared. Idle capacity can be borrowed, but a long-running task cannot be instantly preempted; strict requirements need non-borrowable reserved quota.

Wait Aging. Long-waiting tasks gradually promote in priority; within the same level, order by first enqueue timestamp. Timestamps are persisted; retries must not refresh the timestamp. An independent scanner handles not-yet-claimed tasks; do not wait for the consumption callback to promote, because if a task never gets dispatched, the callback never runs.

Aging is only a supplement. If sustained incoming workload exceeds processing capacity, rate limiting, scaling, or degradation is still required; algorithms cannot create capacity.

5. Implementation: Don't Scan from Highest Level Every Time

For simple cases, separate queues and separate worker pools suffice. When unified scheduling is needed, first write messages idempotently into a persistent task table, commit the transaction, then acknowledge the MQ, letting the task system take over subsequent execution.

The entry point must also reserve pull capacity for each level; if low-priority tasks cannot even enter the task table, downstream fair scheduling cannot save them.

Below is a pseudocode demonstration of weighted pulling over shared capacity (application-level):

// One valid coordinator per shard; cursor persists across calls.
Priority[] wheel = {H, H, N, H, H, N, H, H, N, B};
int cursor = 0;

TaskLease nextTask() { // called only when a worker thread is idle
    for (int i = 0; i < wheel.length; i++) {
        Priority p = wheel[cursor];
        cursor = (cursor + 1) % wheel.length;
        // Atomic claim: expired, dependencies met, oldest task in that level.
        TaskLease task = tasks.claimOldestReady(p);
        if (task != null) return task;
    }
    return null;
}

After claiming, lease recovery is needed for crashes; on completion, verify the current lease token. Business updates, idempotency records, and completion status should commit in the same transaction; external actions continue using stable business idempotency keys. Acknowledging takeover only means the task is persisted; monitoring must track through to final result.

Also avoid pre-fetching a large batch into a thread pool; that merely moves the ordinary queue into memory, leaving urgent tasks unable to cut in.

6. Usage and Acceptance Criteria

Verification codes and marketing notifications suit tiering; payment and shipping for the same order have dependencies, so even urgent tasks cannot skip prerequisite steps. Priority is assigned by trusted services with per-tenant quotas; callers must not freely choose the highest level.

Failed tasks need backoff and retry budgets; they must not repeatedly jump the queue under the guise of "urgent." Expired verification codes can be dropped, but payment result notifications may require reconciliation; do not discard uniformly.

Continuous high-priority load tests verify ordinary tasks still complete; long-running tasks saturate threads to observe actual urgent task wait times. Monitoring tracks per-level oldest unfinished age, execution latency, and completion count — not just aggregate throughput.

Lightweight notifications favor separate queues with resource reservation; cross-tenant, high-duration-variance tasks warrant unified scheduling. Without capacity bounds and bounded execution times, do not promise deterministic maximum wait.