What are the two main ways to implement the Priority Queue messaging pattern, and what does each cost you compared to the other?

## The first concrete decision The Priority Queue pattern can be implemented in two structurally different ways, and the choice between them is one of the first concrete decisions a team makes when adopting it. ## Queue-per-tier — multiple physical queues The first approach is multiple physical queues, sometimes called 'queue-per-tier.' You provision separate queues — say, `orders-high`, `orders-normal`, `orders-low` — and producers decide, at publish time, which queue a given message belongs in based on some priority-determining attribute: customer SLA tier, message type, business criticality, or an explicit priority field set by the calling service. Consumers then implement a dispatch policy across those queues: - the simplest is **strict precedence** (always fully drain `orders-high` before touching `orders-normal`, and so on); - but production systems more often use **weighted polling** (e.g., poll high 70% of cycles, normal 25%, low 5%); - or reserve **dedicated consumer capacity** per tier so lower tiers always make some forward progress. This approach's biggest strength is portability: it requires nothing from the broker beyond the ability to have multiple named queues, so it works identically on Amazon SQS, Kafka topics, Google Pub/Sub, or a self-hosted broker with no priority concept at all. Its cost is operational multiplication — N queues to provision, name, monitor for depth and age, alert on, and scale consumers for — and correctness risk in the routing logic itself, since a message misclassified into the wrong queue silently loses (or gains) priority with no error raised anywhere. ## Broker-native priority — a single queue with a priority value The second approach is broker-native priority, where a single queue accepts a priority value on each message and the broker itself is responsible for delivering higher-priority messages ahead of older, lower-priority ones still sitting in that same queue. RabbitMQ is the most commonly cited example: declaring a queue with the `x-max-priority` argument set (say, to 10) tells the broker to maintain up to 10 internal priority levels and always offer the highest available one to a ready consumer. This collapses what would be N queues into one, which simplifies topology, monitoring, and producer code (publish to one place, set a priority header). The cost is twofold. 1. **A broker-specific feature.** First, it's a broker-specific feature — moving to a broker without equivalent support (plain SQS standard queues, for instance, have no priority concept at all) means re-architecting. 2. **A real performance cost.** Second, it has a real performance cost: maintaining priority ordering requires extra bookkeeping compared to a plain FIFO queue, so throughput per message is measurably lower, and that cost grows as the queue gets deeper — exactly the scenario (a large backlog) where you'd most want priority to matter. Broker documentation typically recommends keeping the number of discrete priority levels small (RabbitMQ suggests roughly 1-10) rather than using the field as a fine-grained numeric ranking, both because more levels compound the bookkeeping cost and because fine-grained levels rarely map to meaningfully different business decisions anyway. ## A hybrid of the two There's a hybrid worth naming too: some teams combine both — a small number of broker-native priority levels within each of a small number of physical queues, e.g., separate queues per major SLA class, with fine-grained priority within each queue for tie-breaking. This is more setup work but avoids forcing every distinction into either a rigid tier count or an unwieldy queue count. ## Deciding in practice The decision in practice comes down to a few concrete questions. 1. **Does the broker already support it?** Does the broker already in use support native priority, and does its documented level limit fit the number of tiers actually needed? 2. **How deep do queues get?** How deep do queues realistically get — if backlogs regularly reach hundreds of thousands of messages, the broker-native approach's per-message overhead becomes a real throughput concern, favoring separate queues with independently scaled consumer pools instead. 3. **How much tooling already exists?** How much operational tooling already exists for managing many queues — teams with mature per-queue dashboards, autoscaling, and alerting can absorb queue-per-tier's multiplication more easily than teams doing it manually. 4. **How strict must the granularity be?** And how strict does the priority granularity need to be — a small, stable number of tiers (e.g., critical/normal/low) fits broker-native priority well; a large or evolving set of priority classes tends to be easier to reason about, test, and scale as separate queues. ## A concrete case A concrete case: a payments platform running on RabbitMQ used a single priority-enabled queue for transaction events, giving fraud-review holds priority 9 and routine settlement events priority 1-3. This worked cleanly at moderate volume, but during a Black Friday spike the queue depth crossed several hundred thousand messages and per-message latency degraded broker-wide, including for unrelated queues on the same node — prompting the team to split fraud-review events into their own dedicated queue with its own consumer pool, decoupling its throughput entirely from settlement volume.