Walk into a busy hospital emergency room and you'll notice it isn't first-come-first-served. Someone arriving with chest pains is seen before someone who's been waiting an hour with a sprained ankle. A nurse triages everyone and the most urgent cases move to the front, because order of arrival matters less than how critical the case is.
A priority queue brings that triage logic to your system. Instead of processing requests in the strict order they arrived, it lets more important work be handled first.
The problem
A plain queue is fair in the simplest way: first in, first out. Everything waits its turn. That's fine until not all work is equally important. A flood of low-stakes background jobs — say, batch report generation — can pile up in the queue, and now a time-sensitive request, like a paying customer's checkout confirmation, is stuck behind thousands of items it doesn't care about.
Strict FIFO has no notion that some messages deserve to be handled sooner. During a busy spell, the requests that matter most are exactly the ones most likely to be buried, and your most valuable users feel the slowest service.
Step through a busy spell below, and predict how long the urgent job waits before you see the answer.
How it works
You attach a priority to each message and let consumers honor it. There are two common ways to build this. One is a single queue that natively understands priority, dequeuing the highest-priority message available rather than the oldest. The other — often simpler and more portable — is to use separate queues per priority level: a high-priority queue and a low-priority one, with consumers always draining the high queue first and only reaching for the low queue when the high one is empty.
You can also tune capacity per level: put more competing consumers on the urgent queue so it clears fast, and fewer on the routine one. Either way, urgent work no longer waits behind the routine backlog.
Below, the same two workers and the same checkout run again, this time with two queues and one rule: check the high queue first. Predict when the checkout starts, then flip to Single FIFO to compare the two runs step by step.
Look at what didn't change: in both runs, the last job finished at the same moment. A priority queue adds no capacity. It only decides who waits, and that has two practical consequences.
First, priority can't rescue an overloaded system. If work arrives faster than your workers can finish it, someone still waits; with priorities, that someone is everything in the low queue. Second, workers don't drop a job halfway for an urgent one. They pick urgent work next, so an urgent message can still wait as long as the routine jobs already in progress. If a routine job takes ten minutes, so can that wait. Split long jobs into short chunks, or dedicate a few consumers to the high queue alone, so someone is always free when urgent work lands.
Your workers always check the high-priority queue first, yet urgent messages sometimes wait 10 minutes. The low-priority jobs are video transcodes that take about 10 minutes each. What's going on?
Beware starvation. If high-priority work keeps arriving, a naive 'always serve high first' rule means low-priority messages may never run. Reserve some consumer capacity for the low queue, or age messages up in priority the longer they wait, so routine work still drains instead of rotting at the bottom forever.
When to use it
A priority queue makes sense whenever your workload has a genuine mix of urgencies — premium versus free tiers, interactive requests versus background batch jobs, or alerts that must be acted on immediately alongside routine processing. It pairs naturally with queue load leveling, which smooths bursts, by adding a sense of which buffered work to tackle first.
Don't bother if all your messages are equally important — a plain FIFO queue is simpler and has no starvation risk to manage. And keep the number of priority levels small; two or three tiers capture most of the value, while a dozen finely graded levels just add complexity without making the system meaningfully smarter about what to do next.
During a week-long sale, high-priority orders arrive nonstop, and every worker always takes from the high queue first. What happens to the nightly reports in the low queue?