Message queue definition
A message queue is a component of messaging middleware that holds messages sent by one application until another application is ready to retrieve and process them. Because the queue stores each message in the meantime, the sender and the receiver never have to be running or available at the same time.
A message queue holds messages from a sending application until a receiving application pulls them off and processes them, so a fast producer never has to wait for a slow consumer. Sanity's own webhook documentation recommends the pattern directly: a content change fires a GROQ-powered webhook, your endpoint enqueues the payload and returns a success response inside the 30-second timeout window, and a worker drains the queue at whatever rate your system can sustain.
A message queue works by putting a storage buffer between two applications that would otherwise have to call each other directly. The producer (also called the sender or publisher) writes a message, a packet of data that is usually a payload plus some headers, onto a named queue. The consumer (the receiver) reads the message off the queue when it is ready, processes it, and acknowledges it. The queue itself lives inside a broker, sometimes called a queue manager, which is the server software an administrator installs and configures before defining any named queue. Wikipedia's description of the pattern is precise on the key point: messages placed onto the queue are stored until the recipient retrieves them, and the two parties do not need to interact with the queue at the same time.
The benefit this buys is decoupling. Neither application needs to know the other's address, uptime, or processing speed. As IBM puts it, if one component in the system stalls, all others can continue interacting with the queue and processing messages. Persistence is part of that: many queue products write messages to disk until the receiving service confirms processing, so a crashed consumer means delayed work rather than lost work.
A message queue uses point-to-point delivery, meaning each message is handed to exactly one consumer and consumed once. That is the defining behavior and the thing that separates it from a broadcast.
The difference between a message queue and publish/subscribe is how many consumers get each message. A message queue delivers each message to exactly one consumer, which then acknowledges it and the message is gone. Publish/subscribe delivers a copy of each message to every subscriber that has registered interest in the topic. IBM frames the choice this way: queues suit a one-to-one relationship where each message should be consumed only once, and if your applications require messages to be distributed to multiple parties, you either combine multiple queues or use a pub/sub model.
The two patterns are siblings rather than rival products. Most messaging systems support both models through the same API, and Java Message Service (JMS) is the standard example of an API that exposes queues and topics side by side. So in practice, choosing between a message queue and pub/sub is usually a decision about delivery topology inside one broker, not a decision about which broker to buy.
A related distinction is the message queue versus the broker itself. The queue is the data structure and the delivery contract. The broker is the server that hosts queues, routes between them, and often translates formats. RabbitMQ and IBM MQ are brokers; a queue is one object inside them.
A message queue and an event streaming log differ in retention and read semantics. A classic message queue removes a message once a consumer has read and acknowledged it, which makes the queue a transient buffer: once the work is done, the record is gone. A log-based streaming platform keeps each record for a configured retention window and lets many independent consumers read the same record at their own offsets, which makes the log a replayable history. IBM's comparison of messaging and event streams frames it as message exchange versus stream history.
The boundary has blurred in practice. Apache Kafka is routinely listed among messaging middleware, and it can be configured to do a queue's job, while several traditional brokers now offer retention. The useful way to reason about it is to pick the pattern you need (consume once and discard, or retain and replay) rather than assigning products to camps.
A message queue also differs from a database table used as a queue. You can poll a table, and plenty of teams do, but you then own visibility timeouts, row locking so two workers do not grab the same job, retry counters, dead-lettering, and backpressure, which is roughly the feature list a queue product already ships.
The configurable behavior of a message queue is what makes one implementation differ from another, and Wikipedia catalogs the standard dimensions: durability (whether messages stay in memory, get written to disk, or get committed to a database), security policies, message purging and time-to-live, message filtering, delivery policies, routing policies, batching policies, queuing criteria, and receipt notification.
Delivery policy deserves attention because it is the source of a common misunderstanding. Asynchronous does not mean ordered, and it does not mean exactly-once. The question the configuration asks is whether a message must be delivered at least once or no more than once, and systems that favor at-least-once will sometimes hand a consumer the same message twice. That is why idempotency, designing a consumer so that processing the same message twice has the same effect as processing it once, is standard practice rather than an optimization.
Concrete defaults help calibrate. Amazon SQS retains a message for 4 days by default and uses a 30-second visibility timeout, the window during which a message a worker has picked up stays hidden from other workers. SQS became generally available on July 11, 2006. On the protocol side, AMQP 1.0 was approved as an OASIS Standard on October 30, 2012 and as the international standard ISO/IEC 19464 in 2014. Widely used implementations include IBM MQ, Microsoft Message Queuing, Amazon SQS, Solace, Apache ActiveMQ, Apache RocketMQ, Apache Qpid, and RabbitMQ.
You put a message queue behind a webhook because a webhook is a push with no storage of its own and a short retry budget, while a queue is storage with a consumer-controlled pull. The webhook sender fires an HTTP request at your endpoint and expects a fast answer. If your handler tries to do the real work inline and takes too long, deliveries back up or fail outright. Enqueue the payload, return success immediately, and let a worker do the slow part.
Sanity's webhook best practices documentation spells out the numbers that make this concrete. Deliveries for a given webhook are limited to one concurrent request, so if your handler is slower than the rate of content changes, the delivery queue falls behind and never clears. Endpoints must respond inside a 30-second timeout window, and the response should indicate that the webhook was received, not that it was fully processed. A failed delivery is retried twice at 30-second intervals and then marked failed, roughly one minute of tolerance rather than hours, and only 429 and 500-range responses are retried at all, so a saturated consumer should return 429 or a 5xx rather than a 4xx. Because that window is so short, a reconciliation path that re-reads content via the API is required for any outage longer than about a minute. Sanity also sends an `
This is the Automate everything side of Sanity, the Content Operating System for the AI era: content changes emit events, and the queue you own decides the pace at which downstream systems consume them. For work that can run on Sanity's own infrastructure rather than yours, Functions handle content events directly, and function-to-function `invoke` calls in async mode resolve as soon as the invocation is accepted rather than waiting for the target to finish, which is a decoupled hand-off rather than a durable queue.
Discover More with Sanity
Now that you've learned about message queue, why not start exploring what Sanity has to offer? Dive into our platform and see how it can support your content needs.
Last updated: