Message Queues
A message queue buffers work between producers and consumers. It lets producers submit tasks without waiting for processing, and lets consumers work at a controlled rate. Correct queue use depends on delivery, acknowledgement, duplicate handling, ordering, expiry, and dead-letter policies.
itDistributed systems, messaging, and integration | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Message Queues
A message queue is the polite waiting room between somebody who has work and somebody who can do it. A producer puts a message in. A consumer takes it when ready. This arrangement prevents every burst of incoming work from marching straight into a database, API, or other dependency and demanding immediate attention. The queue has not performed the work. It has merely kept the ticket from blowing away in the breeze.
The useful shape is producer, enqueue, retain, receive, process, and acknowledgement. That last word is doing rather a lot of lifting. It tells the queue that a consumer accepted a delivery. If the consumer acknowledges too early and then fails, the work can disappear. If it acknowledges after the effect and fails at the awkward moment between them, the queue can send the message again. This is not the queue being indecisive. It is the system admitting that two machines cannot always exchange a perfectly reassuring final nod.
That is why idempotency matters. A consumer must make repeated delivery safe, often by using a durable key for the intended effect. The queue can smooth a rush of work, but it cannot make a permanently slow consumer catch up. Watch backlog and oldest message age. Add consumers only while their database or external service can tolerate the added pressure. Otherwise the queue has kindly moved the traffic jam to a more expensive junction.
Ordering is also smaller than it first sounds. Parallel consumers usually give up one global order. If one customer, order, or account needs serialized work, identify that key and accept the scaling limit around it. When messages expire, are malformed, or fail repeatedly, use a dead-letter queue with the reason, attempts, and safe context. Then decide whether to fix and replay, compensate, or discard under retention policy. A dead-letter queue is a work queue with better paperwork, not a cellar where problems become vintage.
Read the intro for the complete lifecycle and failure choices. Use the slides for the flow and capacity trade-offs. Keep the cheatsheet nearby when naming controls and signals. The practice reference and exercise turn the acknowledgement boundary into a small, safe experiment. The quiz checks whether the vocabulary has stopped pretending it is interchangeable. That is enough machinery to begin asking the right questions before a queue is asked to become magic.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://learn.microsoft.com/en-us/azure/architecture/patterns/queue-based-load-leveling
Supports
- Queue buffering
- load leveling
- backlog
- idempotency
- ordering
- dead-letter handling
- and capacity considerations
- https://www.enterpriseintegrationpatterns.com/patterns/messaging/
Supports
- Queue
- competing consumers
- idempotent receiver
- and dead-letter vocabulary
- https://github.com/stn1slv/awesome-integration
Supports
- Message queue ecosystem discovery
- https://www.rabbitmq.com/tutorials
Supports
- Queue tutorial progression
- https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html
Supports
- Managed queue service documentation
- https://nats.io/
Supports
- Persistent work-queue messaging
- https://activemq.apache.org/
Supports
- Open-source messaging
- https://www.rabbitmq.com/
Supports
- RabbitMQ product landscape and local practice environment
- https://activemq.apache.org/components/artemis/
Supports
- Apache ActiveMQ Artemis product landscape
- https://kafka.apache.org/
Supports
- Apache Kafka product landscape
- https://aws.amazon.com/sqs/
Supports
- Amazon SQS product landscape
- https://azure.microsoft.com/en-us/products/service-bus/
Supports
- Azure Service Bus product landscape
- https://cloud.google.com/pubsub
Supports
- Google Cloud Pub/Sub product landscape
- https://www.rabbitmq.com/resources/erlang-exchange-talk-final/ex
Supports
- AMQP work beginning in 2004
- AMQP 0.8
- and RabbitMQ's first public release
- https://www.rabbitmq.com/blog/2024/08/05/native-amqp
Supports
- AMQP 0.8 and AMQP 1.0 publication dates
- https://www.rabbitmq.com/blog/2010/08/27/growing-up
Supports
- RabbitMQ 2.0 scalable storage engine and persistence API
- https://www.amqp.org/node/102.html
Supports
- AMQP 1.0 approval as an OASIS Standard
- https://www.rabbitmq.com/blog/2023/05/17/rabbitmq-3.12-performance-improvements
Supports
- RabbitMQ 3.6 lazy queues
- https://www.rabbitmq.com/blog/2021/07/13/rabbitmq-streams-overview
Supports
- RabbitMQ Streams introduction
- https://www.rabbitmq.com/blog/2022/03/29/at-least-once-dead-lettering
Supports
- At-least-once dead lettering and failure modes of at-most-once transfer
- https://stripe.com/blog/idempotency
Supports
- Idempotency keys
- retry behavior
- and duplicate-effect prevention
