RabbitMQ و AMQP (و مقایسه با Kafka، JMS و MQTT)RabbitMQ & AMQP (vs Kafka, JMS and MQTT)

In the Kafka chapter you learned what a distributed log is. Now we go to the other broker family that job ads demand just as loudly: the queue-oriented brokers, headed by RabbitMQ.

These are not two tools for one job. Kafka is a diary anyone can re-read from any page; RabbitMQ is a post office that delivers the letter to the right mailbox, and once delivered it is no longer there. Every architectural decision falls out of that one sentence.

We start from zero with no term left undefined — but finish where a senior has to stand: "what do we set prefetch to", "why did your retry take production down", "why Kafka is wrong here".

1. Why a broker at all?

Three things a broker gives you that HTTP does not: decoupling, buffering (if the receiver dies, messages wait instead of turning into 500s), and back-pressure. And one thing it does not: correctness of your logic — a message arrives at least once, so consumers must be idempotent.

AMQP stands for Advanced Message Queuing Protocol, and here lies a big trap:

• AMQP 0-9-1: the protocol RabbitMQ was built around, with the exchange/binding/queue model. When people in the RabbitMQ world say "AMQP", this is it.
• AMQP 1.0: a completely different protocol with a similar name — an OASIS and ISO/IEC 19464 standard, with no exchange model, only nodes, links and flow. Azure Service Bus and ActiveMQ Artemis speak this one. They are not two versions of one thing but two independent protocols with confusingly similar names.

Since 4.0 RabbitMQ speaks AMQP 1.0 natively, not through a translating plugin: both 0-9-1 and 1.0 clients connect on port 5672. The 4.x line also removed classic queue mirroring in 4.0, made the Raft-based metadata store Khepri the default in 4.2, and in 4.3 (April 2026) made Khepri the only option, gave quorum queues up to 32 priority levels and native delayed retries, and raised the minimum Erlang/OTP to 27.

2. The AMQP 0-9-1 model from zero

Producer: the application that sends a message. The key, counter-intuitive point: a producer never publishes directly to a queue; it always publishes to an exchange.

Exchange: the routing box — it takes the message, applies its rules and decides which queue(s) it lands in; if none matches, the message is silently discarded. Queue: a named FIFO buffer; the queue holds the message, not the exchange. Binding: the rule connecting an exchange to a queue ("anything matching this pattern goes here"), optionally with a binding key. Routing key: the string the producer stamps on the message — the address on the envelope, compared against binding keys.

Consumer: the application that receives from a queue and acks after processing. Connection: a TCP connection to the broker; expensive (handshake, TLS, authentication). Channel: a lightweight virtual connection multiplexed over that TCP, on which every AMQP command runs. Virtual host (vhost): a logical namespace holding exchanges, queues, bindings and permissions (default /) — like a database schema, for separating environments or teams.

The whole model at a glance | کل مدل در یک نگاه:

flowchart LR
  P[Producer] -->|"basic.publish + routing key"| X{{Exchange}}
  X -->|"binding key: order.created"| Q1[[Queue: billing]]
  X -->|"binding key: order.*"| Q2[[Queue: audit]]
  X -->|no binding matched| D[Dropped or returned]
  Q1 -->|basic.deliver| C1[Consumer A]
  Q2 -->|basic.deliver| C2[Consumer B]
  C1 -.->|basic.ack| Q1

Every AMQP message has three parts: a method frame (the command, e.g. basic.publish), a content header (the properties) and one or more body frames. The properties worth knowing: delivery_mode (1 transient, 2 persisted), content_type, headers (the table a headers exchange routes on), correlation_id/reply_to for request/reply, expiration (a per-message TTL in milliseconds, as a string), and message_id, the unique id deduplication is built on.

3. The four exchange types

Picture four clerks: direct drops the letter in a box only if the address matches its label exactly; fanout ignores the address and drops a copy into every box; topic splits the address on dots and matches patterns; headers opens the envelope and reads the internal labels.

Direct is an exact, byte-for-byte match between routing key and binding key:

# rabbitmqadmin v2 — a standalone Rust binary, the second generation HTTP API tool
rabbitmqadmin declare exchange --name payments --type direct --durable true
rabbitmqadmin declare queue --name payments.captured --type quorum --durable true
rabbitmqadmin declare binding --source payments --destination payments.captured \
  --destination-type queue --routing-key captured

A message with routing key captured arrives; Captured does not.

Fanout ignores the routing key and copies the message into every bound queue. It is the fastest type since it matches nothing, but 50 bound queues multiply write throughput by 50.

Topic is the workhorse: the routing key is split on dots and the binding key gets two wildcards — * matches exactly one word, # matches zero or more.

Picture four bindings on the amq.topic exchange: order.*.created, order.eu.#, # and order.eu.created. Now see where each message lands:

Note that order.eu.# also catches order.eu, because # can match zero words — exactly the question interviewers ask.

Order routing keys general to specific, because wildcards gain meaning from the left: order.eu.created beats created.eu.order because it lets you bind order.#. Never put a high-cardinality id in a routing key (order.1234567.created) — ids belong in the payload or headers. The limit is 255 bytes.

Headers ignores the routing key and matches on the headers table. The binding carries an x-match argument: all means every listed header must match (AND), any means one is enough (OR); recent versions add all-with-x and any-with-x, which include headers starting with x-. A binding with x-match=all, format=pdf and locale=fa-IR only catches messages carrying both.

Headers is slower than topic (map matching instead of optimised string matching); use it only for genuinely multi-dimensional matching. Every vhost ships with "" (default, direct), amq.direct, amq.fanout, amq.topic, amq.headers/amq.match and amq.rabbitmq.trace.

4. Queue types: classic, quorum, stream

Map<String, Object> args = Map.of(
        "x-queue-type", "quorum",
        "x-dead-letter-exchange", "orders.dlx",
        "x-delivery-limit", 5,             // the 4.x default is 20
        "x-max-length", 100_000,
        "x-overflow", "reject-publish");   // required for at-least-once dead-lettering

channel.queueDeclare("orders.work", /* durable */ true,
                     /* exclusive */ false, /* autoDelete */ false, args);

Three operational notes: use an odd replica count (3 or 5; even numbers only add cost); the queue must stay short; and exclusive or auto-delete queues cannot be quorum — for an RPC reply queue keep a classic exclusive one.

Streams arrived in 3.9: a replicated append-only log where consuming does not remove the message; the consumer holds an offset and can start from the beginning, a given offset or a timestamp. A super stream is that stream partitioned across several physical streams — a Kafka topic, each stream a partition. Its protocol lives on port 5552, but you can also consume over AMQP 0-9-1 (x-stream-offset).

5. Durability and persistence — the triple everyone gets wrong

Three independent things exist, and all three must be right or the message is lost:

1. Durable queue: the queue definition is stored in broker metadata and recreated on restart. A non-durable queue vanishes on restart with all of its contents.
2. Persistent message: published with delivery_mode = 2, so the broker writes it to disk; delivery_mode = 1 means memory only.
3. Publisher confirm: the publisher waits for the broker's acknowledgement that the message really was accepted and stored.

When the broker "writes a message to disk" it first writes only to the OS page cache; if the power goes, that data is not yet on physical media, and fsync forces the flush. For classic queues RabbitMQ batches writes and fsyncs periodically, so there is a small loss window — and publisher confirms are exactly what closes it. For quorum queues the rule is stronger: the confirm arrives once the entry is written to a majority of replicas, tolerating the loss of a whole machine.

The publisher confirm flow and its guarantee | جریان publisher confirm و آنچه تضمین می‌کند:

sequenceDiagram
  participant P as Publisher
  participant B as Broker
  participant Q as Durable / quorum queue
  P->>B: confirm.select
  B-->>P: confirm.select-ok
  P->>B: basic.publish (delivery_mode=2, tag 1)
  B->>Q: route + persist / replicate to majority
  Q-->>B: durable
  B-->>P: basic.ack (tag 1)
  P->>B: basic.publish (bad routing key, tag 2)
  B-->>P: basic.return (mandatory)
  B-->>P: basic.ack (tag 2)
  Note over P,B: ack does NOT mean routed. Watch returns too.

channel.confirmSelect();   // put this channel into confirm mode

channel.addConfirmListener(
    (tag, multiple) -> outstanding.headMap(tag, true).clear(),          // ack
    (tag, multiple) -> log.error("broker nacked delivery tag {}", tag)); // nack

channel.addReturnListener(ret ->
    log.error("unroutable: exchange={} rk={}", ret.getExchange(), ret.getRoutingKey()));

AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
        .deliveryMode(2)                                  // persistent
        .messageId(UUID.randomUUID().toString())
        .contentType("application/json")
        .build();

channel.basicPublish("orders", "order.eu.created", /* mandatory */ true, props, body);

Three confirm styles exist: one-at-a-time synchronous (throughput disaster), batched with waitForConfirmsOrDie for batch pipelines, and asynchronous with a ConfirmListener — the right choice for online services.

AMQP 0-9-1 also has transactions (tx.select / tx.commit) with a similar guarantee but 10 to 100 times slower, since every commit is a synchronous fsync; a channel also cannot be transactional and in confirm mode at once. In practice: always confirms, never transactions.

6. Consumer acknowledgements and prefetch

Auto-ack (autoAck = true): as soon as the broker writes the message to the socket it considers it removed; if the consumer dies before processing it is gone — and it applies no flow limit whatsoever. Manual ack: you say explicitly what happened.

basic.reject is standard AMQP and single-message only; basic.nack is RabbitMQ's extension carrying the multiple flag. requeue = false means dead-lettering (or dropping, with no DLX); requeue = true puts the message back near the head. Careful: multiple=true asserts "all earlier messages succeeded too" — processing out of order, it silently acks unfinished messages.

prefetch is a waiter's tray: taking one plate at a time means constant walking, stacking twenty means plate twenty arrives cold and a trip spills all of them. Concretely it is how many unacked messages the broker will hand one consumer at once.

// prefetchSize must be zero; RabbitMQ does not implement it
// global=false means "per consumer", global=true means "per channel"
channel.basicQos(0, 50, false);

The message lifecycle as the broker sees it | چرخهٔ عمر پیام از دید broker:

stateDiagram-v2
  [*] --> Ready: published and routed
  Ready --> Unacked: basic.deliver to a consumer
  Unacked --> [*]: basic.ack
  Unacked --> Ready: basic.nack requeue=true
  Unacked --> DeadLettered: basic.nack requeue=false
  Unacked --> DeadLettered: delivery-limit exceeded
  Ready --> DeadLettered: TTL expired or max-length
  DeadLettered --> [*]: consumed from the DLQ

try {
    process(msg);
    channel.basicAck(tag, false);
} catch (Exception e) {
    channel.basicNack(tag, false, true);  // ← a time bomb
}

7. DLX, TTL, delays, priority — and retries done properly

A dead-letter exchange (DLX) is just an ordinary exchange that a queue points at. Four situations send a message there, each with its own reason: rejected (rejected with requeue=false), expired (message or queue TTL elapsed), maxlen (the queue hit x-max-length/x-max-length-bytes) and delivery_limit (quorum queues only).

RabbitMQ stamps an x-death header on the message: records with count, reason, queue, routing-keys and original-expiration — a treasure for debugging and counting attempts. Creating the DLX and DLQ is three commands: declare exchange --name orders.dlx --type fanout, declare queue --name orders.dlq --type quorum, and a declare binding between them.

A subtlety for quorum queues: dead-lettering is at-most-once by default, so a message can be lost between source and target. If your dead-lettered messages are valuable:

rabbitmqctl set_policy dlq-reliable "^orders\.work$" \
  '{"dead-letter-strategy":"at-least-once","overflow":"reject-publish","max-length":200000}' \
  --priority 10 --apply-to queues

Careful: at-least-once only works with overflow: reject-publish; with drop-head (the default) it silently falls back to at-most-once. And since the source queue retains dead-lettered messages until confirmed, max-length is required too.

TTL lives in three places: per message via expiration; per queue via x-message-ttl; and on the queue itself via x-expires, which deletes an unused queue (perfect for temporary RPC queues).

For delayed messages you have three routes. Route 1 — the official rabbitmq_delayed_message_exchange plugin: it adds an exchange type called x-delayed-message; you publish with an x-delay header (milliseconds) and the broker holds the message back.

// after rabbitmq-plugins enable rabbitmq_delayed_message_exchange
channel.exchangeDeclare("orders.delayed", "x-delayed-message", true, false,
                        Map.of("x-delayed-type", "topic"));

AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
        .deliveryMode(2)
        .headers(Map.of("x-delay", 30_000))   // 30-second delay
        .build();
channel.basicPublish("orders.delayed", "order.eu.retry", true, props, body);

The plugin targets delays of seconds to a few hours, not multi-day scheduling; recent releases require RabbitMQ 4.x with Khepri; and being outside the broker core it is less durable than a quorum queue.

Route 2 — the TTL + DLX queue ladder (no plugin, works everywhere), diagrammed below. Route 3 — quorum queues' native delayed retry in RabbitMQ 4.3: the cleanest option on 4.3, because the queue sets the returned message aside internally and only makes it available again after the delay, without rewriting it and with no risk of duplication or loss. Configure with x-delayed-retry-type (disabled by default, all, returned, failed) and x-delayed-retry-min, or the policy keys; the back-off is linear.

For priority, set x-max-priority and keep levels low (5 to 10; each is a separate structure inside the broker). Priority only orders messages still in the queue, and a prefetched message is no longer the broker's to reorder, so a large prefetch neutralises priority. Before 4.3 only classic queues supported it; since 4.3 quorum queues offer up to 32 strict levels.

The retry ladder, blocking no consumer | نردبان retry — بدون بلاک‌کردن هیچ consumer‌ای:

flowchart LR
  APP{{orders exchange}} --> W[[orders.work]]
  W -->|"reject requeue=false"| RX{{orders.retry.dlx}}
  RX -->|attempt 1| R1[["retry.5s (ttl 5000)"]]
  RX -->|attempt 2| R2[["retry.30s (ttl 30000)"]]
  RX -->|attempt 3| R3[["retry.5m (ttl 300000)"]]
  R1 -.->|dead-letter back| APP
  R2 -.->|dead-letter back| APP
  R3 -.->|dead-letter back| APP
  W -->|"attempts exhausted"| PARK[[orders.parking-lot]]

rabbitmqadmin declare queue --name retry.30s --type quorum --durable true \
  --arguments '{"x-message-ttl":30000,"x-dead-letter-exchange":"orders","x-dead-letter-routing-key":"order.eu.created"}'

No consumer ever sits on the retry.* queues: the queue simply holds the message until the TTL elapses.

8. Idempotent consumers and deduplication

Because delivery is at-least-once, every consumer must swallow duplicates harmlessly. Three levels: naturally idempotent operations (UPDATE account SET status = 'ACTIVE' WHERE id = ? can run a thousand times); a unique key in the database; and an inbox table recording the message id in the very transaction that does the work:

CREATE TABLE processed_message (
    message_id   text        PRIMARY KEY,
    consumer     text        NOT NULL,
    processed_at timestamptz NOT NULL DEFAULT now()
);

-- inside the same transaction that performs the real work
INSERT INTO processed_message (message_id, consumer)
VALUES ('7f3c1e8a-...', 'order-projector')
ON CONFLICT (message_id) DO NOTHING;

CREATE TABLE processed_message (
    message_id   VARCHAR2(128) PRIMARY KEY,
    consumer     VARCHAR2(64)  NOT NULL,
    processed_at TIMESTAMP WITH TIME ZONE DEFAULT SYSTIMESTAMP NOT NULL
);

-- Oracle has no ON CONFLICT; use MERGE (or catch ORA-00001)
MERGE INTO processed_message t
USING (SELECT '7f3c1e8a-...' AS message_id, 'order-projector' AS consumer FROM dual) s
   ON (t.message_id = s.message_id)
WHEN NOT MATCHED THEN
  INSERT (message_id, consumer) VALUES (s.message_id, s.consumer);

If nothing was inserted the message was already processed — skip the work and just ack. On the publisher side sits the outbox table; safe batched reads with parallel workers:

SELECT id, aggregate_id, payload
FROM outbox
WHERE published_at IS NULL
ORDER BY id
FOR UPDATE SKIP LOCKED
LIMIT 100;

SELECT id, aggregate_id, payload
FROM outbox
WHERE published_at IS NULL
ORDER BY id
FETCH FIRST 100 ROWS ONLY
FOR UPDATE SKIP LOCKED;

Three pieces of senior judgement: prune the dedup table with a cleanup job sized from the maximum possible message age, or it becomes an incident of its own; let the publisher generate message_id, because a consumer hashing content collapses two genuinely different events with identical payloads into one; and keep the dedup record in the same transaction as the work — dedup in Redis evaporates on a flush or eviction. The outbox, inbox and saga patterns are covered in the ms-data chapter.

9. Operations: clustering, alarms, flow control and metrics

RabbitMQ nodes talk over Erlang distribution: port 4369 for epmd (name discovery) and 25672 for distribution itself, and all nodes share one Erlang cookie. A client can connect to any node; if it is not the queue's leader the request is forwarded inside the cluster — one extra hop, but transparent. Each quorum queue is an independent Raft cluster with a leader and followers.

Broker metadata (queues, exchanges, bindings, users) lived in Mnesia for years, which handled network partitions poorly. Khepri is the Raft-based replacement — the same algorithm quorum queues use — default since 4.2 and the only option in 4.3. The practical effect: partition behaviour is more predictable, but on the minority side schema changes (declaring a queue or exchange) fail until the majority returns.

RabbitMQ has two resource alarms and both do one thing: block publishers. A memory alarm fires when node memory exceeds vm_memory_high_watermark (today's default 0.6, i.e. 60% of detected RAM), and a disk alarm when free space falls below disk_free_limit (default 50 MB, which is only suitable for tutorials).

# rabbitmq.conf
vm_memory_high_watermark.relative = 0.6
disk_free_limit.relative = 2.0             # twice RAM — the practical production advice
consumer_timeout = 1800000
cluster_partition_handling = pause_minority

rabbitmq-plugins enable rabbitmq_management   # port 15672
rabbitmq-plugins enable rabbitmq_prometheus   # port 15692, path /metrics

# HTTP API — queue depth and consumers (%2F is the default "/" vhost)
curl -s -u guest:guest 'http://localhost:15672/api/queues/%2F/orders.work' \
  | jq '{messages_ready, messages_unacknowledged, consumers}'

# ready-made health checks for probes
curl -s -u guest:guest http://localhost:15672/api/health/checks/alarms
curl -s -u guest:guest http://localhost:15672/api/health/checks/node-is-quorum-critical

Never build a two-node cluster: with two nodes a majority is impossible, so if one dies the other cannot decide anything either — for both quorum queues and Khepri the right number is 3 (or 5). And keep queues short: a long queue is not merely "slow", it drives memory up, starts paging to disk, spikes latency, and eventually trips the alarm that blocks every publisher.

Default ports: 5672/5671 (AMQP without/with TLS), 15672 (management), 15692 (Prometheus), 25672 (Erlang distribution), 4369 (epmd), 5552 (stream), 1883/8883 (MQTT), 61613/61614 (STOMP).

10. Spring AMQP in practice

spring-boot-starter-amqp wraps the official Java client with two main tools: RabbitTemplate for publishing and @RabbitListener for consuming.

spring:
  rabbitmq:
    virtual-host: /orders
    publisher-confirm-type: correlated   # async confirms with correlation data
    publisher-returns: true
    template:
      mandatory: true                    # without this, publisher-returns does nothing
    listener:
      simple:
        acknowledge-mode: auto           # the container acks unless an exception escapes
        prefetch: 20
        concurrency: 4
        max-concurrency: 16
        default-requeue-rejected: false  # ← critically important
        retry:
          enabled: false                 # leave retries to the broker, not to memory

@Bean
RabbitTemplate rabbitTemplate(ConnectionFactory cf) {
    RabbitTemplate template = new RabbitTemplate(cf);
    // in Spring AMQP 4.x the class is named JacksonJsonMessageConverter
    template.setMessageConverter(new Jackson2JsonMessageConverter());
    template.setConfirmCallback((correlation, acked, cause) -> {
        if (!acked) log.error("publish nacked id={} cause={}", correlation, cause);
    });
    template.setReturnsCallback(r ->
        log.error("unroutable exchange={} rk={}", r.getExchange(), r.getRoutingKey()));
    return template;
}

void publish(OrderCreated event) {
    rabbitTemplate.convertAndSend("orders", "order.eu.created", event,
            message -> {
                MessageProperties p = message.getMessageProperties();
                p.setDeliveryMode(MessageDeliveryMode.PERSISTENT);
                p.setMessageId(event.id().toString());
                return message;
            },
            new CorrelationData(event.id().toString()));
}

@RabbitListener(queues = "orders.work", concurrency = "4-16")
public void onOrderCreated(@Payload OrderCreated event,
                           @Header(name = "x-death", required = false)
                           List<Map<String, Object>> deaths) {

    long attempt = (deaths == null || deaths.isEmpty())
            ? 0L : (Long) deaths.get(0).get("count");

    try {
        orderService.handle(event);          // must be idempotent
    } catch (InvalidPayloadException e) {
        // permanent error → straight to the DLQ, never retried
        throw new AmqpRejectAndDontRequeueException("bad payload", e);
    } catch (DownstreamUnavailableException e) {
        if (attempt >= 5) {
            throw new AmqpRejectAndDontRequeueException("attempts exhausted", e);
        }
        throw e;                             // → goes to the retry ladder
    }
}

Subtleties worth catching in code review:

• Two container types: SimpleMessageListenerContainer (default; consumer count adjustable at runtime) and DirectMessageListenerContainer (listener.type=direct; a thread per consumer, lower overhead). For high, steady load direct is usually better.
• Listener-side retry.enabled retries in memory and holds the thread: fine for a few hundred milliseconds, a disaster for multi-minute backoff. For application-side retries combine RepublishMessageRecoverer with a RetryTemplate, so the message is finally published to an error queue with its stack trace instead of merely rejected.
• Manual acks tie the ack to an asynchronous event: acknowledge-mode: manual plus a Channel parameter.

@SpringBootTest
@Testcontainers
class OrderListenerIT {

    @Container
    @ServiceConnection     // Spring Boot injects host/port/credentials itself
    static RabbitMQContainer rabbit =
            new RabbitMQContainer(DockerImageName.parse("rabbitmq:4.1-management"));

    @Autowired RabbitTemplate rabbitTemplate;
    @Autowired RabbitAdmin rabbitAdmin;

    @Test
    void routesToDlqOnPermanentFailure() {
        rabbitTemplate.convertAndSend("orders", "order.eu.created", brokenEvent());

        Awaitility.await().atMost(Duration.ofSeconds(10)).untilAsserted(() ->
            assertThat(rabbitAdmin.getQueueInfo("orders.dlq").getMessageCount())
                .isEqualTo(1));
    }
}

On Testcontainers 1.x the dependency is org.testcontainers:rabbitmq (class in org.testcontainers.containers); in 2.x it is org.testcontainers:testcontainers-rabbitmq with the package org.testcontainers.rabbitmq.

Three things worth an integration test that mocks never give you: binding correctness (does that routing key really reach that queue?), the DLQ path, and idempotency (same message twice, identical final state?). Testcontainers fundamentals are in the testing chapter.

11. RabbitMQ vs Kafka, JMS and MQTT

The fundamental difference in one sentence: RabbitMQ is a queue, Kafka is a log. In RabbitMQ the message disappears after the ack; in Kafka it stays until retention ends and the offset is a pointer.

What are JMS and Jakarta Messaging?

A misunderstanding that gets exposed fast in interviews: JMS is not a protocol, it is an API — a set of Java interfaces. What goes over the wire is up to the broker and is not standardised, which is why one vendor's JMS client generally cannot talk to another vendor's broker. AMQP is the opposite: a wire protocol, independent of language.

After moving to the Eclipse Foundation, JMS became Jakarta Messaging and the packages moved from javax.jms to jakarta.jms; the current version is 3.1. Apache ActiveMQ Artemis (2.44.x at the time of writing) is the most prominent open-source implementation and is multi-protocol: AMQP 1.0, MQTT, STOMP, OpenWire and its own core protocol.

Artemis is still right in three situations: a Jakarta EE mandate with MDBs (@MessageDriven) on an application server (see ms-runtime-legacy); a genuine need for XA transactions, which RabbitMQ lacks; and message selectors, consumer-side filtering on properties (JMSType = 'urgent' AND region = 'EU'), which in RabbitMQ must become routing topology. For a new polyglot service a wire protocol almost always beats a Java-only API.

MQTT — where RabbitMQ reaches the device world

MQTT targets low-bandwidth networks and constrained devices; its fixed header can be just 2 bytes against dozens in HTTP — for a battery-powered sensor on a cellular network, months of extra life.

Core concepts: a topic is levelled with / (sensors/floor2/room7/temp) with wildcards + (one level) and # (multi-level, only at the end). QoS 0 is at most once, QoS 1 at least once, QoS 2 exactly once. Retained message: the last message per topic is kept so a new subscriber immediately gets the "current state". LWT: a message the device registers on connect that the broker publishes for it on an abnormal disconnect. Clean session: whether subscriptions survive a disconnect.

With rabbitmq-plugins enable rabbitmq_mqtt (ports 1883 and 8883) plus rabbitmq_web_mqtt for WebSocket the mechanism is elegant: the MQTT message is published to amq.topic with the topic translated into a routing key — / becomes . and + becomes *. So the device publishes MQTT and the backend consumes AMQP 0-9-1, with no bridge in between. One queue is created per subscriber (classic, quorum, or rabbit_mqtt_qos0_queue); Native MQTT since 3.12 cut per-connection memory sharply, and MQTT 5.0 arrived in 3.13.

Decision tree: which broker family fits | درخت تصمیم:

flowchart TD
  S{"Need replay of past events?"} -->|yes| K["Kafka or RabbitMQ Streams"]
  S -->|no| R{"Per-message routing, TTL, priority or DLQ?"}
  R -->|yes| RM["RabbitMQ queues (AMQP 0-9-1)"]
  R -->|no| T{"Many constrained or intermittent devices?"}
  T -->|yes| M["MQTT (or RabbitMQ MQTT plugin)"]
  T -->|no| J{"Jakarta EE app server or XA required?"}
  J -->|yes| A["JMS broker: ActiveMQ Artemis"]
  J -->|no| RM