In a Priority Queue setup with separate high- and low-priority queues, strict 'always serve high-priority first' consumer logic can starve the low-priority queue during sustained high-priority load. Name two concrete techniques to prevent this, and explain how each works.

## Why naive priority starves the lower tier Starvation is the single most important failure mode of the Priority Queue pattern, and it's worth understanding precisely why naive implementations produce it. If a consumer's dispatch logic is simply 'check the high-priority queue; if it has any message, process it; only look at the low-priority queue when high-priority is empty,' then any workload where high-priority messages arrive faster than they can be drained — even briefly, even for an hour during a spike — means the low-priority queue receives zero processing time for the entire duration. Low-priority work is usually still real, necessary work (welcome emails, report generation, data sync jobs), just work with a looser latency requirement; when it's starved rather than merely delayed, that looseness gets violated in an unbounded way, and what was meant to be a minutes-or-hours SLA silently becomes a days-or-weeks one, which can itself become a customer-facing incident. ## The first mitigation — guarantee forward progress The first mitigation is to change the dispatch policy from strict precedence to something that guarantees forward progress on lower tiers regardless of higher-tier backlog. - **Weighted round-robin polling.** The simplest version is weighted round-robin polling: instead of always checking high-priority first, a consumer loop is configured to poll high-priority queues, say, 8 out of every 10 cycles and low-priority queues 2 out of every 10, so low-priority work always gets a fixed floor of throughput. - **Dedicated reserved capacity.** A more robust version, common in production, is dedicated reserved capacity: rather than one shared consumer pool making per-cycle polling decisions, each tier gets its own independently sized and independently scaled consumer pool — e.g., a fixed minimum of 2 consumers permanently assigned to the low-priority queue no matter how large the high-priority backlog grows, with high-priority separately autoscaled to absorb its own spikes. This removes any coupling between the two tiers' processing rates entirely; a runaway high-priority backlog can't starve low-priority because they don't share a resource pool at all. ## The second mitigation — message aging The second mitigation is message aging, also called **priority escalation**. The idea is that a message's effective priority is not fixed at creation time but increases the longer it has waited unprocessed, until it eventually becomes high-priority regardless of its original tier. This can be implemented a few ways: - recomputing an effective priority score at dequeue/poll time as a function of base priority and time enqueued, if the broker or consumer logic supports dynamic scoring; - or, more commonly with simple brokers, a scheduled job that periodically scans the low-priority queue for messages older than some threshold (say, 30 minutes) and re-publishes them into the high-priority queue, typically after removing them from the low-priority queue, or marking them so they aren't double-processed. Aging guarantees a hard upper bound on wait time for any message — no matter how much higher-priority traffic keeps arriving, a message can only age for so long before it becomes high-priority itself and gets picked up. ## What each one costs | Mitigation | The bill it comes with | |---|---| | Dedicated reserved capacity | The cost is resource inefficiency during quiet periods — those reserved low-priority consumers sit mostly idle when there's little low-priority work — and the operational overhead of running and monitoring more independent consumer groups. | | Message aging | The cost is complexity: you need reliable tracking of enqueue time, careful handling to avoid processing an aged message twice (once from its original queue, once from its escalated position), and the aging threshold itself becomes another piece of configuration that has to be tuned and monitored. | ## Combining both, and what to watch In practice, mature systems often combine both: reserved minimum capacity as a baseline guarantee, plus aging as a safety net that further protects against edge cases like a single consumer pool falling behind. Both techniques share the same underlying principle — priority should bound how long something waits, not whether it ever runs at all — and both require the same operational discipline: queue depth and oldest-message-age need to be first-class monitored metrics per tier, with alerting on age (not just depth), since a queue can have modest depth and still contain a message that's dangerously old if throughput has degraded. ## Where it shows up A concrete real-world scenario: a ride-hailing platform routes ride-matching events (must be processed within seconds) and post-ride receipt/analytics events (fine within hours) through separate queues sharing infrastructure. During a surge event, ride-matching volume triples for several hours. Because the platform had allocated a fixed minimum of 15% of total consumer capacity permanently to the receipt/analytics queue — rather than letting ride-matching consumers pull from it opportunistically — receipts continued to process throughout the surge, just more slowly, instead of stalling completely and creating a multi-hour backlog that would have taken far longer to work through once the surge subsided.