Competing Consumers
A worker pool pulls from one queue so throughput scales horizontally.
StarterMessagingPlatform
Work items land on a single queue; any number of identical workers compete to pull and process them. Scaling out is adding workers, not repartitioning producers.
When to use it
- Background work has variable volume and needs elastic throughput
- Each message should be processed exactly once, by exactly one worker
Trade-offs
- No ordering guarantee across messages processed by different workers
- A slow poison message can block a worker until it is retried or dead-lettered
Components used
Serverless FunctionMessage QueueContainer Service
How it works
- Many identical workers read from the same queue. Each message is delivered to exactly one of them.
- The broker handles distribution, so scaling throughput is simply a matter of adding workers.
- Messages are acknowledged only after successful processing; an unacknowledged message becomes visible again for another worker.
Used in the wild
- Background job processing — image resizing, report generation, email sending.
- Absorbing traffic spikes by letting the queue buffer while workers drain at a steady rate.
- Any embarrassingly parallel workload where messages are independent.
Good to know
- Ordering is the casualty. Once several workers pull concurrently, messages complete out of order, which is why ordered processing requires partitioned keys instead.
- Redelivery means at-least-once, not exactly-once. Handlers must be idempotent, because a worker that crashes after doing the work but before acknowledging will cause the work to be done twice.
Related patterns
Model Serving with A/B Testing
Route inference traffic across model versions to compare live performance.
CQRS
Separate models and stores for writes and reads.
Change Data Capture
Stream a database's row-level changes without touching app code.
Blue-Green Deployment
Run two full production environments, switch traffic between them.