What is a message queue? Async communication explained
A message queue is a component that lets different parts of an application communicate asynchronously by passing messages through a buffer — one part adds messages, another processes them later, so the two never have to be available at the same time. That sounds like a small technical detail, but it is one of the most consequential decisions in distributed system design: it is the difference between an application where one slow or failing part drags everything else down with it, and one where each part can fail, recover and catch up independently. This article explains the problem message queues solve, how they work conceptually, their benefits, how they differ from publish/subscribe, and where the pattern appears in certification study.
The problem it solves
Imagine service A calls service B directly to get something done — process a payment, resize an image, send a notification. If B is slow, A waits. If B is down, A fails, even though A itself did nothing wrong. This is tight coupling: the reliability and performance of the whole system is limited by its weakest, most tightly connected link, and a spike in traffic to A becomes an instant spike in load on B, whether B is ready for it or not.
A message queue breaks that direct dependency. Instead of A calling B and waiting, A drops a message describing the work into a queue and moves on immediately. B reads from the queue and processes messages whenever it is ready — a moment later, or after recovering from an outage. Neither side needs to know whether the other is currently available.
How it works, conceptually
Three roles make up the pattern. A producer is the part of the system that creates a message and puts it on the queue — it does not wait for anyone to process it. The queue itself is a buffer that holds messages until they are collected, typically preserving order and ensuring nothing is lost even if a consumer is temporarily unavailable. A consumer reads messages from the queue and does the actual work, at its own pace.
The word “asynchronously” is doing the real work in that description: the producer’s job is done the moment the message is queued, regardless of when — or how quickly — it actually gets processed. That separation in time is what makes the whole pattern useful.
Why this matters: decoupling, resilience, scalability
The benefits all follow from that one separation. Decoupling means producers and consumers do not need to know about each other’s implementation, availability or speed — they only need to agree on the shape of a message. Resilience means a consumer going down temporarily does not lose work; messages simply wait in the queue until it recovers. Scalability means you can add more consumers to work through a queue faster during busy periods, without changing anything about how producers send messages.
The property that ties these together is load levelling: a sudden burst of traffic becomes a longer queue rather than a crashed service. A slow consumer does not fail under a spike — it just works steadily through the backlog, at its own sustainable pace, until it catches up.
Queues versus publish/subscribe
A plain queue is typically point-to-point: each message is delivered to, and processed by, one consumer. Publish/subscribe (often built around “topics”) is different — a message published to a topic can be delivered to every subscriber interested in it, not just one. Both are asynchronous and both decouple producers from consumers, but a queue distributes work across consumers, while a topic broadcasts an event to everyone who needs to know about it. Many real systems use both: a topic to announce that something happened, and one or more queues downstream to actually process the resulting work.
Messaging services in AWS, Azure and Google Cloud
Each major cloud provider offers managed services for both patterns rather than expecting you to run your own message broker. On AWS, SQS (Simple Queue Service) is the classic point-to-point queue, while SNS (Simple Notification Service) provides the publish/subscribe side, and the two are commonly used together. Microsoft Azure offers Service Bus for enterprise-grade queuing and topics, alongside the simpler Queue Storage. Google Cloud offers Pub/Sub, which covers the publish/subscribe pattern at global scale. Knowing which pattern — queue or topic — a scenario calls for is more important than memorising any one service’s configuration options.
Where this shows up in architecture
Message queues are a foundational building block of event-driven architecture and microservices, where independent services need to communicate without becoming tightly coupled to each other’s availability — the same coupling problem covered in our explainer on monolithic versus microservices architecture. Breaking a monolith apart without introducing queues or events between the pieces tends to just recreate the same tight coupling in a more complicated form.
This pattern is also a recurring scenario in AWS Solutions Architect Associate exam questions: a design needs to handle unpredictable load, or two components need to be decoupled so one’s failure does not cascade to the other, and a queue is very often the correct answer. It shows up in the AWS Developer Associate exam too, from the application-building side — knowing when to reach for SQS versus SNS in your own code. Our revision sections cover the exam-level detail for each provider’s specific service.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.
Questions, answered
Get the study material as it lands
Occasional email when we publish a new certification, guide or set of practice questions. No spam, unsubscribe in one click.