A message queue is a piece of middleware that lets separate systems communicate asynchronously. A sender places a message onto the queue and continues its own work; one or more receivers consume messages from the queue later, on their own schedule. The queue sits between the two, holding messages until they can be processed, which decouples the sender from the receiver in both time and availability: neither needs the other to be running at the same instant.
This decoupling is the central value. The Apache Kafka introduction emphasizes the same idea for streaming systems, noting that “producers and consumers are fully decoupled and agnostic of each other,” a property that lets each side scale and fail independently. In a classic queue, a message is usually delivered to a single consumer and removed once it has been acknowledged, which makes queues a natural fit for distributing work items across a pool of workers.
Many systems implement this pattern, including RabbitMQ, ActiveMQ, and cloud services such as Amazon SQS. Log-based systems like Kafka generalize it: rather than discarding a message on consumption, Kafka retains events in a durable, ordered log, so the same data can be read by many independent consumers and replayed. In his Confluent writing, Jay Kreps presents this commit-log approach as a way to get queue-like decoupling while keeping the messages around as a lasting record.
Message queues underpin much of modern distributed architecture. By buffering bursts of traffic, smoothing load between fast producers and slower consumers, and isolating failures, they let large systems be built from small services that talk to each other indirectly rather than through tightly coupled direct calls.