Priority Queue
Separate lanes so urgent work is never stuck behind bulk work.
StarterMessaging
High-priority messages are routed to a dedicated lane with its own worker pool, so a burst of low-priority bulk work cannot starve time-sensitive requests.
When to use it
- Some messages (e.g. password resets) must not wait behind bulk jobs (e.g. newsletters)
- A single FIFO queue is causing head-of-line blocking for urgent work
Trade-offs
- Two lanes to monitor and scale instead of one
- Still needs a policy for what counts as high priority, or producers will mislabel everything
Components used
Serverless FunctionMessage QueueContainer Service
How it works
- Work is separated into distinct queues by urgency rather than sorted within one queue.
- Dedicated worker pools — or workers that check the high-priority queue first — ensure urgent items are never stuck behind bulk work.
- Separate lanes also mean a flood of low-priority work cannot exhaust capacity for high-priority work.
Used in the wild
- Interactive requests competing with nightly batch jobs on the same worker fleet.
- Paid tiers receiving faster processing than free tiers.
- Incident-time operations that must jump ahead of routine work.
Good to know
- Strict priority starves the low lane whenever high-priority volume is sustained. Weighted sharing — say 80/20 — keeps bulk work progressing.
- Separate queues are preferred over a single sorted queue because most brokers cannot efficiently reorder a large backlog, and priority within a partition breaks ordering guarantees anyway.
Related patterns
Change Data Capture
Stream a database's row-level changes without touching app code.
Pub/Sub Fan-out
One event, many independent subscribers acting on it in parallel.
Competing Consumers
A worker pool pulls from one queue so throughput scales horizontally.
Transactional Outbox
Write state and the event to publish in the same local transaction.