{"dataset":{"id":"00000000-0000-0000-0000-000000000042","slug":"rabbitmq-best-practices","name":"RabbitMQ best practices","description":"Source-linked guidance on RabbitMQ fundamentals: queue durability, exchange routing, consumer acknowledgements, TTL and dead lettering, and connection/channel management. Scoped to RabbitMQ; not a general AMQP or messaging corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Long-lived connections and multiplexed channels","sourceUrl":"https://www.rabbitmq.com/docs/channels","text":"RabbitMQ protocols are TCP-based and assume long-lived connections for efficiency — a connection is not opened per protocol operation, and one client library connection uses a single TCP connection. Applications must close connections when they are no longer needed, and a consistently high rate of newly opened connections — connection churn — risks resource exhaustion; RabbitMQ collects churn metrics and exposes them via Prometheus and the management UI. AMQP 0-9-1 connections are multiplexed with channels, lightweight connections that share a single TCP connection; every protocol operation happens on a channel, and a channel exists only within a connection, so closing a connection closes all its channels. For multi-threaded or multi-process applications, open a new channel per thread or process rather than sharing channels between them, and close channels when they are no longer needed because operations on a closed channel fail. The maximum number of channels per connection, channel_max, is negotiated between client and server at connection time and the lower configured value wins; exceeding it closes the connection with an error. Some client libraries provide automatic recovery from network failures; others leave recovery to the application. Scope: RabbitMQ. Reviewed October 4, 2026.","id":"rabbitmq-best-practices:Long-lived connections and multiplexed channels","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Message and queue TTL with dead lettering","sourceUrl":"https://www.rabbitmq.com/docs/ttl","text":"TTL (time-to-live) can be set for messages and for queues. Per-queue message TTL is configured with the x-message-ttl queue argument at declaration or the message-ttl policy key; the value must be a non-negative integer in milliseconds, and 0 expires a message upon reaching the queue unless it can be delivered to a consumer immediately — no basic.return is issued, and the message is dead-lettered if a dead letter exchange is set. Publishers set per-message TTL with the expiration property, whose value must be a string; when both per-queue and per-message TTL are present, the lower value is chosen. The server guarantees that expired messages are not delivered to consumers. Queue TTL expires the queue itself: the x-expires argument or expires policy deletes a queue that has been unused — no consumers, no recent redeclaration, no basic.get — for at least the expiration period; the value must be a positive integer and streams do not support expiration. Expired messages are discarded or dead-lettered: quorum queues dead-letter them when they reach the head of the queue, classic queues at the head or when a policy change affects the queue. Scope: RabbitMQ. Reviewed October 4, 2026.","id":"rabbitmq-best-practices:Message and queue TTL with dead lettering","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Manual consumer acknowledgements and prefetch","sourceUrl":"https://www.rabbitmq.com/docs/confirms","text":"In manual acknowledgement mode the consumer explicitly confirms each delivery: basic.ack for positive acknowledgements, and basic.nack or basic.reject for negative ones — basic.nack is a RabbitMQ extension to AMQP 0-9-1, while basic.reject cannot reject multiple deliveries at once. Deliveries are identified by a delivery tag scoped to the channel, so acknowledging on a different channel fails with an unknown delivery tag protocol error. Setting the multiple field to true acknowledges every delivery tag up to and including the given one, batching acknowledgements to reduce network traffic. Automatic acknowledgement mode treats a message as delivered once it is sent — fire-and-forget — and should be considered unsafe; it can also overload consumers. Manual mode is typically paired with a bounded channel prefetch set via basic.qos, which caps the number of unacknowledged deliveries on a channel; a value of 0 means no limit, and quorum queues cap consumer prefetch at 2,000. Negative acknowledgements with requeue set to true return deliveries to the queue, but requeue/redelivery loops are costly, so limit redeliveries or reject messages for good — discarding or dead-lettering them. Scope: RabbitMQ. Reviewed October 4, 2026.","id":"rabbitmq-best-practices:Manual consumer acknowledgements and prefetch","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Exchange types and routing","sourceUrl":"https://www.rabbitmq.com/docs/exchanges","text":"An exchange's type and its bindings implement the routing logic. Direct exchanges route to bound queues, streams, or exchanges using exact equivalence of the binding's routing key. Fanout exchanges route a copy of every message to every bound queue, stream, or exchange and the routing key is completely ignored. Topic exchanges pattern-match the message routing key against the binding pattern, where * matches exactly one word and # matches zero or more words, so a binding pattern of # makes the topic exchange act like a fanout. Headers exchanges instead use optional binding arguments. The default exchange is a predeclared direct exchange: when a queue is declared, RabbitMQ automatically binds it to the default exchange with the queue name as the routing key, which makes publishing directly to a queue by name convenient. It is not meant to be used as a regular exchange with explicit bindings; declare a separate direct exchange for custom topologies. Bindings inherit durability from their source exchange and destination, and support for semi-durable and fully transient bindings will be dropped in the future. Scope: RabbitMQ. Reviewed October 4, 2026.","id":"rabbitmq-best-practices:Exchange types and routing","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Durable queues for broker restart survival","sourceUrl":"https://www.rabbitmq.com/docs/queues","text":"Queues are durable or transient (non-durable). Metadata of a durable queue is stored on disk, so durable queues are recovered on node boot together with the messages in them that were published as persistent: to survive a broker restart an application must declare durable queues and publishers must mark published messages as persisted. Quorum queues must be durable because of the assumptions and requirements of their underlying replication protocol, and for quorum queues a delivery limit should be set to bound redeliveries. Transient (non-durable) non-exclusive classic queues are deprecated; the alternatives are durable queues, non-durable exclusive queues, or durable queues with a queue TTL for cleanup of unused queues. An exclusive queue can only be used by its declaring connection and is deleted when that connection closes, so exclusive queues should almost always be server-named. Durability does not affect a queue's throughput or latency, and in most cases durable queues are the recommended option. Scope: RabbitMQ. Reviewed October 4, 2026.","id":"rabbitmq-best-practices:Durable queues for broker restart survival","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}