Skip to main content

How Message Queues Work: Internals and Queue Types

Article 1 made the case for message queues — the coupling problem, the five ways a naive array fails, the guarantees a real broker provides. Now let's open the hood.

Understanding what happens inside a queue — the data structures, the acknowledgement state machine, the persistence mechanisms — is what separates a developer who uses a queue from one who can debug it. When a RabbitMQ queue unexpectedly redelivers a message, you'll know why. When a priority queue causes low-priority jobs to starve, you'll recognize the pattern immediately. When your queue's memory climbs and triggers an alarm, you'll know what to tune.

This article builds the mental model that makes every subsequent article feel obvious rather than arbitrary.

Quick Reference​

Queue types at a glance:

TypeData StructureOrder GuaranteeUse When
FIFOLinked list / ring bufferStrict arrival orderMost job queues — email, resize, export
PriorityMin-heapHighest priority firstCritical tasks must not wait behind batch jobs
DelaySorted set by timestampEarliest delivery time firstRetry backoff, scheduled reminders
Circular (ring buffer)Fixed-size array with wraparoundOverwrites oldestLatest-N events, real-time metrics
Dead LetterAny (secondary queue)N/A — receives rejected messagesInspect and replay failed messages

Delivery guarantee quick pick:

  • Accept occasional loss → At-most-once (fire and forget)
  • Need every message processed, can handle rare duplicates → At-least-once (design consumers to be idempotent)
  • Never want duplicates → Exactly-once (implement idempotency keys at application level, on top of at-least-once)

Gotchas:

  • ⚠️ Priority queues can starve low-priority messages if high-priority messages arrive continuously — always set a minimum consumption rate
  • ⚠️ Delay queues in RabbitMQ require a TTL + Dead Letter Exchange pattern (no native delay without the plugin) — covered in Part 4
  • ⚠️ Circular buffers intentionally lose messages — never use for durable job processing

See also:

Read more about queues in this module as other articles become available.

Version Information​

This article covers queue concepts and data structures — not specific library APIs. Concepts apply to RabbitMQ, BullMQ, Kafka, and any message broker.

RabbitMQ-specific notes use:

  • RabbitMQ 4.x
  • Node.js 20.x LTS
  • amqplib 0.10.x

Important RabbitMQ version note: Classic Mirrored Queues were deprecated in RabbitMQ 3.9 and permanently removed in RabbitMQ 4.0. If you are on RabbitMQ 4.x, quorum queues are the correct HA queue type. This article reflects that reality.

What You Need to Know First​

Required reading:

You should be comfortable with:

  • Basic data structures — arrays, linked lists (we'll explain what we need as we go)
  • TypeScript async/await

What We'll Cover in This Article​

By the end of this guide, you'll understand:

  • What data structure sits behind a FIFO queue and why it's the right choice
  • How acknowledgement actually works as a state machine
  • What persistence tiers exist and how a write-ahead log saves messages across restarts
  • The five queue types — FIFO, priority, delay, circular, dead letter — and when to use each
  • The difference between push and pull delivery models, and why it matters

What We'll Explain Along the Way​

We'll introduce these with full explanations:

  • Linked lists and ring buffers (with diagrams)
  • Min-heaps and why priority queues use them
  • Write-ahead logging (WAL)
  • Raft consensus (briefly, for context on quorum queues)
  • Head-of-line blocking and message starvation

Part 1: The Data Structure Behind a FIFO Queue​

Let's start with the simplest queue type — the one you'll use for 80% of job processing work — and understand exactly what it's built from.

The linked list model​

A FIFO queue (First In, First Out) is conceptually a line. The first message in is the first message out. Under the hood, the most natural data structure for this is a doubly linked list — a chain of nodes where each node holds a message and two pointers: one to the next node, one to the previous.

HEAD                                                    TAIL
 │                                                        │
 ▼                                                        ▼
[msg A] ←→ [msg B] ←→ [msg C] ←→ [msg D] ←→ [msg E]
 ▲                                                        ▲
 │                                                        │
Consumer reads                                Producer writes
from here (dequeue)                           here (enqueue)

Diagram: A doubly linked list queue. Producers append to the tail; consumers read from the head. Both operations are O(1) — constant time regardless of queue depth.

Two operations, both O(1) — meaning they take the same time whether the queue has 10 messages or 10 million:

  • Enqueue (publish): Allocate a new node, set it as the tail's next pointer, update the tail pointer. Done.
  • Dequeue (consume): Read the head node, advance the head pointer to the next node. Done.

This is why FIFO queues are fast at any depth. You don't scan the queue to find the next message — you always know exactly where it is.

Why linked lists beat arrays for queues​

You might wonder: why not just use an array and track head/tail indices? Arrays work, but they have a problem: as you consume from the front and produce at the back, you eventually reach the end of the array — even if most of it is empty (the consumed slots). You either shift all remaining elements left (expensive — O(n)) or you use a circular buffer.

Real brokers use circular buffers (ring buffers) for fixed-capacity in-memory queues and linked list-like structures for on-disk or unbounded queues. We'll cover ring buffers when we get to circular queues in Part 4.

What RabbitMQ actually stores​

In RabbitMQ, a queue is an ordered collection of messages providing FIFO semantics. When publishing on a single channel, messages are enqueued in publishing order in every queue they are routed to.

Each node in the queue doesn't just hold the message body — it holds a full message record:

┌──────────────────────────────────────────────┐
│ Message Record                               │
│──────────────────────────────────────────────│
│ delivery_tag    : uint64  (broker-assigned)  │
│ routing_key     : string                     │
│ headers         : map<string, any>           │
│ body            : bytes                      │
│ delivery_mode   : 1 (transient) | 2 (persist)│
│ timestamp       : datetime                   │
│ redelivered     : boolean                    │
│ state           : ready | unacked | acked    │
└──────────────────────────────────────────────┘

The state field is critical. It's the core of the acknowledgement system — which we'll cover next.

Part 2: How Acknowledgement Actually Works​

In Article 1, we described acknowledgement at a high level: the broker keeps a message until the consumer confirms it was processed. Now let's see the actual state machine.

The three-state message lifecycle​

Every message in a real queue moves through exactly three states:

                    consumer picks up message
READY ──────────────────────────────────────► UNACKED
  ▲                                              │
  │                                              │
  │  consumer nacks                              │
  │  (requeue=true)              consumer acks   │
  └──────────────────────────────────────────────┤
                                                 │
                                  consumer nacks │
                                  (requeue=false)│
                                                 ▼
                                              DELETED
                                          (or → DLQ)

Diagram: The three-state message lifecycle. READY → UNACKED happens on delivery. UNACKED → READY happens on nack+requeue (the message goes back to be delivered again). UNACKED → DELETED happens on ack or nack without requeue.

  • READY — the message is sitting in the queue, available for delivery to any consumer. This is where a message spends most of its life.
  • UNACKED — the message has been delivered to a consumer but the consumer hasn't confirmed it yet. The broker knows this consumer has it. If the consumer's connection drops, the broker moves the message back to READY and delivers it to the next available consumer.
  • DELETED (or DLQ'd) — the message is gone from the queue. Either the consumer acknowledged it (success) or nacked it without requeue (failed permanently → goes to dead letter queue if configured).

The in-flight counter and consumer timeouts​

The broker maintains a count of messages in UNACKED state per consumer. This is the prefetch window — we cover it in detail in Article 8. For now, understand this: a consumer has a limit on how many messages it can have unacked simultaneously. If it hits that limit, the broker stops delivering new messages to it until it acks some back.

This is back-pressure at the acknowledgement level.

Consumers should use manual acknowledgements to ensure messages that aren't successfully processed are returned to the queue so that another consumer can re-attempt processing.

There's also a consumer timeout — if a message stays in UNACKED state too long (the consumer is stuck), the broker assumes the consumer is dead and redelivers. In RabbitMQ 4.x, this defaults to 30 minutes and is configurable.

What "redelivered" means​

When a message is returned to READY after a consumer failure and delivered again, the broker sets its redelivered flag to true. Your consumer can use this to detect potential duplicates:

channel.consume("image-resize", async (msg) => {
  if (!msg) return;

  const job = JSON.parse(msg.content.toString());

  // Check the redelivered flag
  if (msg.fields.redelivered) {
    // This job may have already been processed.
    // Check idempotency before proceeding.
    const alreadyProcessed = await db.jobResults.exists(job.id);
    if (alreadyProcessed) {
      console.log(
        `[Worker] Job ${job.id} already processed — skipping duplicate`,
      );
      channel.ack(msg); // Ack it so the broker stops redelivering
      return;
    }
  }

  try {
    await resizeImage(job.imageKey);
    await db.jobResults.create({ jobId: job.id, completedAt: new Date() });
    channel.ack(msg); // ✅ Success — remove from queue
  } catch (err) {
    console.error(`[Worker] Job ${job.id} failed:`, err.message);
    channel.nack(msg, false, false); // Send to DLQ — don't loop forever
  }
});

Key insight: The redelivered flag tells you "this message has been delivered before." It does not tell you whether it was successfully processed — you have to check that yourself. This is why idempotency logic lives in your application, not the broker.

Part 3: Persistence — How Messages Survive Restarts​

A queue in memory is fast but fragile. A persistent queue survives crashes, restarts, and power failures. Let's understand how that works.

The three persistence tiers​

Every message broker sits somewhere on this spectrum:

TierMechanismSurvives restartSpeedUsed by
In-memory onlyRAM❌FastestRedis (default), transient RabbitMQ queues
Write-ahead logAppend-only disk log✅MediumRabbitMQ (persistent messages), PostgreSQL
Log-based storageImmutable append-only log, indexed✅High at scaleKafka, RabbitMQ Streams

What a write-ahead log (WAL) is​

A write-ahead log is an append-only file on disk. Before any message is acknowledged to the producer, the broker writes it to this log. The log is the source of truth. If the process crashes, the broker replays the log on startup and reconstructs its in-memory state.

Here's the sequence for a persistent message in RabbitMQ:

1. Producer sends message with delivery_mode: 2 (persistent)
2. RabbitMQ receives the message frame
3. Message is written to the WAL on disk (fsync — forced to disk, not just OS cache)
4. Message is placed in the queue's in-memory linked list (for fast delivery)
5. Broker sends basic.ack back to producer (publisher confirm)
   ↕
   Crash here → on restart, WAL is replayed → message reappears in queue ✅
6. Consumer picks up message → state: UNACKED
7. Consumer sends basic.ack
8. Message removed from WAL and in-memory queue

The critical rule: the broker acknowledges the producer only after the message is safely on disk. This is what "durable" means in practice.

What happens when the WAL gets big​

Brokers don't keep every message in the WAL forever. Once a message is acknowledged by a consumer, it's eligible for removal. The broker periodically compacts the WAL — rewriting it with only the unacknowledged messages, discarding the consumed ones.

This compaction is why you sometimes see I/O spikes on a message broker under heavy load. It's expected behavior — but it means you shouldn't co-locate RabbitMQ on the same disk as a database or other I/O-heavy service.

Persistent messages vs durable queues — two separate settings​

This trips up almost everyone when they first use RabbitMQ. You need both:

// ✅ Durable queue: the queue definition survives a broker restart
await channel.assertQueue("image-resize", {
  durable: true, // Queue survives restart — but what about the messages?
});

// ✅ Persistent message: the message body survives a broker restart
await channel.sendToQueue(
  "image-resize",
  Buffer.from(JSON.stringify(job)),
  { persistent: true }, // Message written to WAL — survives restart
);

// ❌ This combination is a silent trap:
await channel.assertQueue("image-resize", { durable: true });
await channel.sendToQueue("image-resize", Buffer.from(JSON.stringify(job)));
// persistent defaults to false — messages vanish on restart even though queue survives!

The rule: If you want messages to survive a broker restart, you need durable: true on the queue AND persistent: true on each message. One without the other does not give you durability.

Part 4: Queue Types — The Full Taxonomy​

Now that you understand the underlying mechanics, let's walk through the five queue types. Each has a specific data structure, a specific use case, and specific failure modes to watch out for.

Type 1: FIFO Queue​

Data structure: Doubly linked list (or ring buffer for fixed-capacity queues).

Guarantee: Messages are delivered in the order they arrive.

Use when: Order matters and all jobs have equal priority — email sending, file exports, sequential data processing.

Head-of-line blocking — the FIFO gotcha:

FIFO queues have one notable failure mode: if the consumer at the head of the queue is slow or stuck, everything behind it waits. Imagine a report generation job that takes 10 minutes sitting in front of 500 password reset emails.

Some RabbitMQ queue features such as priorities and requeueing by consumers can affect the ordering as observed by consumers.

The fix is either a priority queue (covered next) or separate queues for different job classes — don't mix fast and slow jobs in the same queue.

// Pattern: separate queues by job class, not a single shared queue
await channel.assertQueue("emails-auth", { durable: true }); // High-urgency: password reset, 2FA
await channel.assertQueue("emails-transact", { durable: true }); // Medium: receipts, confirmations
await channel.assertQueue("emails-batch", { durable: true }); // Low: newsletters, digests

// Separate consumer pools, each scaled independently

Type 2: Priority Queue​

Data structure: Min-heap (also called a binary heap).

Guarantee: Higher-priority messages are delivered before lower-priority messages, regardless of arrival order.

Use when: Some jobs are more urgent than others and must not wait behind lower-priority work — password reset emails must not wait behind newsletter sends.

What a min-heap is​

A min-heap is a tree structure where every parent node has a value less than or equal to its children. The minimum value is always at the root. You can extract the minimum in O(log n) time — much slower than FIFO's O(1), but it gives you priority ordering.

Priority: lower number = higher urgency

         [priority: 1]          ← root (highest priority, delivered first)
        /              \
  [priority: 3]    [priority: 2]
    /       \
[p: 5]   [p: 4]

Diagram: A min-heap. The lowest priority number (highest urgency) is always at the root and is delivered first. Inserting a new message requires "bubbling up" to maintain the heap property.

RabbitMQ priority queues​

RabbitMQ supports priority queues via the x-max-priority queue argument. You set a maximum priority level (1–255, though the docs recommend no more than 10 for performance), and each message can carry a priority value within that range.

// Declare a priority queue with max priority of 10
await channel.assertQueue("jobs", {
  durable: true,
  arguments: {
    "x-max-priority": 10, // Priority range: 1 (low) to 10 (high)
  },
});

// Publish a high-priority password reset job
await channel.sendToQueue(
  "jobs",
  Buffer.from(JSON.stringify({ type: "password-reset", userId: "u_123" })),
  {
    persistent: true,
    priority: 10, // Highest priority — goes to front of queue
  },
);

// Publish a low-priority newsletter job
await channel.sendToQueue(
  "jobs",
  Buffer.from(JSON.stringify({ type: "newsletter-send", campaignId: "c_456" })),
  {
    persistent: true,
    priority: 1, // Lowest priority — waits behind everything else
  },
);

The starvation problem​

Here's where priority queues bite you. If high-priority messages arrive continuously, low-priority messages never get processed. This is called starvation.

Timeline:
t=0:  [p:1 newsletter] arrives
t=1:  [p:10 reset]     arrives → delivered first
t=2:  [p:10 reset]     arrives → delivered first
t=3:  [p:10 reset]     arrives → delivered first
...
t=∞:  [p:1 newsletter] still waiting 😬

The fix: dedicate a separate consumer or consumer pool exclusively to low-priority work, running at a minimum consumption rate. Or use separate queues for each priority class instead of a single priority queue.

Practical advice: In most systems, separate queues per urgency class (e.g., emails-auth, emails-batch) are simpler to operate and reason about than a single priority queue. Use priority queues only when jobs arrive dynamically with varying urgency and you truly need the ordering within a single consumer pool.

Type 3: Delay Queue (Scheduled Queue)​

Data structure: Sorted set, ordered by scheduled delivery timestamp.

Guarantee: Messages become available to consumers only after their scheduled time.

Use when: Retry with exponential backoff ("try again in 60 seconds"), scheduled reminders ("send email in 24 hours"), deferred processing.

How it works internally​

A delay queue is essentially a sorted set where the sort key is the delivery timestamp. A background process (a "sweeper") polls the sorted set, finds all entries whose delivery time ≤ now, and moves them to the main FIFO queue for consumption.

Sorted set (ordered by scheduled_at):

scheduled_at    | message
----------------|--------
2025-07-14 10:00 | retry job #1234
2025-07-14 10:05 | reminder email u_789
2025-07-14 11:30 | report generation c_456

Sweeper runs every second:
  "Is 10:00 ≤ now? Yes → move job #1234 to main queue"
  "Is 10:05 ≤ now? No → stop scanning"

Delay queues in RabbitMQ — the TTL + DLX pattern​

RabbitMQ does not have a native delay queue without the rabbitmq-delayed-message-exchange plugin. Without the plugin, you implement delay via message TTL + dead letter exchange:

  1. Messages are published to a "holding" queue with a TTL (time-to-live)
  2. When the TTL expires, the message is considered "dead" and routed to a dead letter exchange
  3. The dead letter exchange routes the message to the main work queue
  4. The consumer picks it up from the work queue — with the delay naturally elapsed
// Step 1: Declare the dead letter (work) exchange and queue
await channel.assertExchange("work.exchange", "direct", { durable: true });
await channel.assertQueue("work.queue", { durable: true });
await channel.bindQueue("work.queue", "work.exchange", "image.resize");

// Step 2: Declare the delay holding queue
// Messages here expire after the TTL and are forwarded to work.exchange
await channel.assertQueue("delay.60s", {
  durable: true,
  arguments: {
    "x-message-ttl": 60_000, // Messages expire after 60 seconds
    "x-dead-letter-exchange": "work.exchange", // Expired messages go here
    "x-dead-letter-routing-key": "image.resize", // With this routing key
  },
});

// Step 3: To schedule a job for 60 seconds from now,
// publish it to the holding queue (NOT the work queue)
async function scheduleWithDelay(
  job: ResizeJob,
  delayMs: number,
): Promise<void> {
  // Use a holding queue that matches the delay duration
  const delayQueue = `delay.${delayMs}ms`;

  // Ensure this delay queue exists
  await channel.assertQueue(delayQueue, {
    durable: true,
    arguments: {
      "x-message-ttl": delayMs,
      "x-dead-letter-exchange": "work.exchange",
      "x-dead-letter-routing-key": "image.resize",
    },
  });

  await channel.sendToQueue(delayQueue, Buffer.from(JSON.stringify(job)), {
    persistent: true,
  });

  console.log(`[Queue] Job scheduled — will be available in ${delayMs}ms`);
}

// Usage: retry this job after 60 seconds
await scheduleWithDelay(
  { imageKey: "uploads/photo.jpg", userId: "u_123" },
  60_000,
);

Why this works: The message sits in the delay queue until its TTL expires. At expiry, RabbitMQ's dead-letter mechanism routes it to the work exchange — which delivers it to the work queue. The consumer picks it up immediately. From the consumer's perspective, the message just showed up at the right time.

The limitation: Each distinct delay duration needs its own holding queue. Dynamic per-message delays (e.g., "delay this specific message by exactly 47 seconds") require a different delay queue per message, or the rabbitmq-delayed-message-exchange plugin which supports arbitrary per-message delays.

Type 4: Circular Buffer (Ring Buffer)​

Data structure: Fixed-size array with two integer indices — head and tail — that wrap around when they reach the end.

Guarantee: The latest N messages are always available. When the buffer is full, the oldest message is overwritten.

Use when: You want the most recent N events, not all events — real-time dashboards, live metrics streams, sensor data feeds.

How the ring buffer works​

Imagine a circular track with 8 slots. A tail pointer marks where the next message will be written. A head pointer marks where the next read will happen. Both advance clockwise.

Initial state (empty):
head=0, tail=0
[ _ ][ _ ][ _ ][ _ ][ _ ][ _ ][ _ ][ _ ]
  0    1    2    3    4    5    6    7

After writing messages A, B, C, D:
head=0, tail=4
[ A ][ B ][ C ][ D ][ _ ][ _ ][ _ ][ _ ]

After consuming A and B:
head=2, tail=4
[ _ ][ _ ][ C ][ D ][ _ ][ _ ][ _ ][ _ ]

After writing E, F, G, H, I (buffer wraps, A overwrites old slot 0):
head=2, tail=1  (tail wrapped past 7 to 0, now to 1)
[ I ][ _ ][ C ][ D ][ E ][ F ][ G ][ H ]
  ^                                      ← newest write at slot 0

Diagram: A ring buffer with 8 slots. Head and tail advance independently. When tail reaches the end of the array, it wraps back to 0. When the buffer is full and a new message arrives, it overwrites the oldest entry (the slot at head).

The key operations are all O(1):

  • Write: Place the message at tail, advance tail = (tail + 1) % capacity
  • Read: Return message at head, advance head = (head + 1) % capacity
  • Full check: (tail + 1) % capacity == head

When to use a ring buffer vs a FIFO queue​

FIFO QueueRing Buffer
Message lossNever (durable)Intentional (overwrites)
MemoryGrows with backlogFixed
Use forDurable job processingLatest-N streaming data

Never use a ring buffer for work that cannot be lost. It is purpose-built for scenarios where the latest data is what matters and old data is irrelevant — dashboards, live feeds, monitoring.

Type 5: Dead Letter Queue (DLQ)​

Data structure: Standard FIFO queue (it's a regular queue that receives specific messages).

Guarantee: Messages that cannot be successfully processed are captured here instead of being silently lost.

Messages end up in the DLQ when:

  • A consumer nacks a message with requeue: false
  • A message expires (TTL elapsed) and the queue has a dead letter exchange configured
  • A queue's length limit is exceeded and overflow policy is reject-publish
  • A message has been rejected more than the queue's configured maximum retry count

The DLQ is not a queue type you "create" — it's the destination you configure for a source queue's rejected messages. You'll learn DLQ configuration in depth in future articles on advanced queue patterns.

The key point here: without a DLQ, a message that cannot be processed has two bad outcomes:

  1. Nack with requeue — infinite loop (the message keeps failing and requeueing forever)
  2. Nack without requeue — silent loss (the message is gone and you have no record of it)

A DLQ gives you a third option: the message goes somewhere safe for inspection and potential replay. This is non-negotiable in production.

Part 5: Push vs Pull — Two Delivery Models​

This distinction matters for understanding why RabbitMQ and Kafka behave differently — and which model fits your use case.

Push model (RabbitMQ's default)​

In a push model, the broker delivers messages to consumers as soon as they're available. The consumer registers interest ("I'm ready to receive messages from this queue") and the broker pushes messages to it.

Broker                        Consumer
  │                               │
  │  consumer.consume('queue')    │
  │ ◄─────────────────────────────┤
  │                               │
  │  basic.deliver (msg 1)        │
  ├──────────────────────────────►│
  │                               │  [processing msg 1]
  │  basic.deliver (msg 2)        │
  ├──────────────────────────────►│
  │                               │  [processing msg 2]
  │  basic.ack (msg 1)            │
  │ ◄─────────────────────────────┤
  │                               │

Diagram: Push delivery. The broker initiates message delivery after the consumer subscribes. The consumer processes and acks; the broker delivers the next message.

Advantages:

  • Lower latency — messages arrive as soon as they're available
  • Simpler consumer code — just register a handler

Disadvantages:

  • The broker must manage flow control (prefetch) to avoid overwhelming slow consumers
  • Consumer must be online and maintain an open connection

RabbitMQ's basic.get — the pull alternative:

RabbitMQ does have a pull method: channel.get('queue-name', { noAck: false }). It lets a consumer explicitly ask for one message at a time, rather than subscribing to a stream of pushed messages.

// Pull model — consumer asks for one message at a time
const msg = await channel.get("image-resize", { noAck: false });
if (msg) {
  await processJob(msg);
  channel.ack(msg);
} else {
  console.log("[Worker] Queue empty — waiting before next poll");
  await sleep(1000);
}

Warning from the RabbitMQ docs: basic.get is discouraged for normal consumption. It requires your application to poll on a timer, which creates unnecessary network traffic and higher latency than push delivery. Use channel.consume() (push) for all production consumers — reserve basic.get for diagnostic scripts or one-off checks.

Pull model (Kafka's model)​

In a pull model, consumers ask the broker for messages on their own schedule. The broker holds messages in a log; consumers track their own position (called an offset) and request the next batch when they're ready.

Kafka Broker (log)               Consumer
[msg 1][msg 2][msg 3][msg 4]        │
                         ▲          │
                    offset=3        │
                                    │  fetch(topic, offset=3, maxBytes=1MB)
                          ◄─────────┤
                                    │
[msg 1][msg 2][msg 3][msg 4] ──────►│
                                    │  [process batch]
                                    │  commit offset=4
                          ◄─────────┤

Diagram: Pull delivery (Kafka). The consumer tracks its own offset and fetches batches at its own pace. The broker doesn't track individual delivery state — the consumer does.

Advantages:

  • Consumer controls its own throughput — no risk of being overwhelmed
  • Replay is trivial — just reset the offset to an earlier position
  • Multiple independent consumer groups can read from the same log at different positions

Disadvantages:

  • Higher latency if consumers poll infrequently
  • Consumer must manage its own offset tracking
  • Not suitable for job queues where each job should be processed once by exactly one consumer

Which model for which use case​

Push (RabbitMQ)Pull (Kafka)
Job queues (one consumer per message)✅ Natural fit❌ Share groups needed (new in Kafka 4.0)
Event streaming (multiple consumers, independent progress)❌ Complex to model✅ Natural fit
Replay historical events❌ Messages deleted after ack✅ Offset reset
Low-latency delivery✅❌ Depends on poll interval
Consumer controls throughputVia prefetch (limited)✅ Full control

Common Misconceptions​

❌ Misconception: "A FIFO queue guarantees strict ordering across all consumers"​

Reality: FIFO guarantees order within a single queue from a single publisher on a single channel. Multiple consumers, redeliveries, and nacks all affect the order a consumer actually observes.

Even if RabbitMQ aims to preserve order, the following will change effective delivery order: message priorities (higher-priority messages may be delivered before lower-priority messages), and multiple active consumers on the same queue (the broker still dequeues in FIFO, but any redelivery can change order).

Why this matters: Don't rely on strict ordering across multiple consumers. If order matters, use a single consumer for order-sensitive jobs, or design your processing to be order-independent.

❌ Misconception: "Priority queues always deliver higher-priority messages first"​

Reality: Priority queues deliver higher-priority messages before lower-priority messages that are already in the queue at the time of dequeue. A high-priority message that arrives after a low-priority message has already been delivered to a consumer doesn't go back in time.

Why this matters: Priority queues are not magic. They optimize delivery order within the queue — they can't affect messages already in-flight (UNACKED).

❌ Misconception: "A durable queue means messages are persistent"​

Reality: durable: true on a queue means the queue declaration (its name, configuration, bindings) survives a broker restart. It says nothing about the messages inside it. For messages to survive, each message must be published with persistent: true (RabbitMQ) or delivery_mode: 2 in AMQP terms.

Example of the trap:

// The queue definition survives restart ✅
await channel.assertQueue("jobs", { durable: true });

// But this message is transient — vanishes on restart ❌
await channel.sendToQueue("jobs", Buffer.from('{"type":"resize"}'));
// Missing: { persistent: true }

❌ Misconception: "A ring buffer is a type of queue for production job processing"​

Reality: A ring buffer intentionally loses data when full. It's purpose-built for scenarios where the latest data is what matters (live metrics, streaming dashboards). Using a ring buffer for durable job processing — orders, payments, file exports — is a serious production incident waiting to happen.

❌ Misconception: "The redelivered flag tells me the job was already completed"​

Reality: The redelivered flag means "this message was delivered at least once before." It does not mean the previous delivery resulted in successful processing. The consumer may have received it, started processing, and crashed. You must check your own idempotency record (a database row, a cache key) to know whether the work was actually done.

Troubleshooting Common Issues​

Problem: Messages are being consumed out of order​

Symptoms: Consumer processes job B before job A, even though A was published first.

Common causes:

  1. Multiple consumers on the same queue — each gets jobs concurrently, so completion order differs from delivery order (90% of cases)
  2. A nacked message was requeued — it goes back to the head of the queue
  3. Priority queue with mixed-priority messages

Diagnostic steps:

// Step 1: Check how many consumers are on this queue
// In the RabbitMQ management UI, click the queue → "Consumers" tab
// If count > 1 and strict order matters → this is expected behavior

// Step 2: Check for nack with requeue in your consumer
channel.consume("my-queue", async (msg) => {
  try {
    await processJob(msg);
    channel.ack(msg);
  } catch (err) {
    // ⚠️ nack with requeue=true puts message back at head of queue
    // This WILL change delivery order
    channel.nack(msg, false, true); // requeue: true ← this is the cause
  }
});

// Step 3: Check if queue has x-max-priority argument
// Priority queues intentionally deliver out of arrival order

Solution: If strict ordering is required, use a single consumer. If you need parallel processing, design your jobs to be order-independent.

Problem: Low-priority jobs never get processed (starvation)​

Symptoms: The priority queue always has low-priority messages sitting unprocessed while high-priority messages flow through.

Common causes:

  1. High-priority messages arrive faster than consumers can process them
  2. Consumer prefetch is set high — consumers always have high-priority messages in their prefetch buffer

Diagnostic steps:

// Step 1: Log priority of each consumed message to verify starvation
channel.consume("priority-queue", async (msg) => {
  const priority = msg.properties.priority;
  console.log(`[Worker] Processing priority: ${priority}`);
  // If you only see high priorities in the logs, starvation is confirmed
  await processJob(msg);
  channel.ack(msg);
});

// Step 2: Check queue depth via management API
const response = await fetch(
  "http://localhost:15672/api/queues/%2F/priority-queue",
  {
    headers: {
      Authorization: "Basic " + Buffer.from("guest:guest").toString("base64"),
    },
  },
);
const queueInfo = await response.json();
console.log("Messages ready:", queueInfo.messages_ready);

Solution: Dedicate a separate consumer exclusively to low-priority messages, running independently of the main consumer pool. Or use separate queues per priority class instead of a single priority queue.

Problem: Delayed messages deliver immediately (ignoring the TTL)​

Symptoms: Messages published to a delay queue are available in the work queue instantly, without waiting for the TTL to expire.

Common causes:

  1. Consumer is attached to the delay queue itself, not the work queue — it picks up messages before TTL expires
  2. The x-dead-letter-exchange argument is missing or misspelled on the delay queue
  3. The delay queue was declared without arguments first (queue redeclaration without arguments ignores new arguments)

Diagnostic steps:

// Step 1: Verify the queue arguments in the management UI
// Go to Queues → click the delay queue → check "Arguments" section
// You should see: x-message-ttl, x-dead-letter-exchange, x-dead-letter-routing-key

// Step 2: Ensure NO consumer is subscribed to the delay queue
// The delay queue should have 0 consumers — messages must expire naturally

// Step 3: Delete and recreate the delay queue if arguments are wrong
// Queue arguments are immutable after declaration — you must delete and redeclare
await channel.deleteQueue("delay.60s");
await channel.assertQueue("delay.60s", {
  durable: true,
  arguments: {
    "x-message-ttl": 60_000,
    "x-dead-letter-exchange": "work.exchange",
    "x-dead-letter-routing-key": "image.resize",
  },
});

Prevention: When using the TTL + DLX delay pattern, always verify queue arguments in the management UI after declaration. Never attach a consumer to the delay queue.

Check Your Understanding​

Quick Quiz​

1. Your image resizer takes 10 seconds per image. Your API publishes jobs 50 times per second. What queue problem will you hit first, and how does the queue handle it?

Show Answer

The producer is outrunning the consumer — 50 jobs/second in, 6 jobs/second out (one every 10 seconds). The queue depth will grow at ~44 messages/second.

Eventually you'll hit one of two limits:

  • Memory limit — the broker runs out of RAM to hold the message records (RabbitMQ starts paging to disk, then blocks producers at 40% memory usage by default)
  • Back-pressure — the broker sends flow control signals to slow producers

Fix: Scale out consumers (more worker processes) and/or set a queue length limit with an appropriate overflow policy. The queue itself handles this — it doesn't silently drop messages; it applies back-pressure.

2. A job is redelivered because your consumer crashed. The redelivered flag is true. What do you actually need to do before processing it?

Show Answer

Check your own idempotency record — not the redelivered flag. The flag tells you the message was delivered before; it does not tell you whether the work was completed. Your consumer should:

  1. Extract the job ID from the message
  2. Query your database (or cache) for a completion record keyed on that job ID
  3. If a record exists: ack the message and skip processing
  4. If no record exists: process the job, create the completion record, then ack

The redelivered flag is a hint to check, not a definitive answer.

3. What's the difference between these two queue declarations, and when would you use each?

// Option A
await channel.assertQueue("metrics", { durable: false });

// Option B
await channel.assertQueue("jobs", {
  durable: true,
  arguments: { "x-message-ttl": 3600000 },
});
Show Answer

Option A — a transient queue. It does not survive a broker restart. Use this for truly ephemeral data where loss is acceptable: live metrics feeds, real-time dashboard events, temporary RPC reply queues.

Option B — a durable queue with a 1-hour message TTL. The queue definition survives a broker restart. Messages older than 1 hour are automatically expired (and dead-lettered if a DLX is configured). Use this for job queues where you want durability but also want to prevent stale jobs from being processed hours later. Note: you still need { persistent: true } on each published message for the messages themselves to survive a restart.

Hands-On Challenge​

The scenario: You're building a notification system. Your system sends three types of notifications:

  • Security alerts (2FA codes, suspicious login warnings) — must be delivered within seconds, never lost
  • Order confirmations — should be delivered within a minute, not critical if 1-2 are lost during a deploy
  • Weekly digest emails — delivered at a scheduled time, can wait, high volume

Your task: Design the queue topology. For each notification type, specify:

  1. Which queue type to use
  2. Whether the queue should be durable
  3. Whether messages should be persistent
  4. Any special arguments (TTL, priority, DLQ)

Justify each choice.

Show Solution

Security alerts:

  • Queue type: FIFO, durable
  • Messages: persistent
  • Arguments: x-dead-letter-exchange → inspect failures; x-max-priority: 10 if mixed with other notifications
  • Justification: Loss is unacceptable. Durable + persistent ensures they survive restarts. DLQ ensures failed deliveries are captured for investigation, not silently lost.
await channel.assertQueue("notifications-security", {
  durable: true,
  arguments: { "x-dead-letter-exchange": "dlx.notifications" },
});

Order confirmations:

  • Queue type: FIFO, durable
  • Messages: persistent (deploy-time loss is a business decision, but durable is safer)
  • Arguments: x-message-ttl: 300000 (5-minute TTL — a confirmation older than 5 minutes is probably not useful)
  • Justification: Durable so the queue survives a restart. TTL prevents stale confirmations from being sent minutes late.
await channel.assertQueue("notifications-orders", {
  durable: true,
  arguments: { "x-message-ttl": 300_000 },
});

Weekly digests:

  • Queue type: Delay queue (TTL + DLX pattern) + FIFO work queue
  • Messages: persistent (these are scheduled — you don't want to lose them)
  • Arguments: Messages published to a delay holding queue, expire at the scheduled send time, routed to the work queue
  • Justification: Digests are scheduled for a future time. Delay queues model this naturally. No DLQ needed — if a digest fails, it's logged and the next week's will run.
// Messages published with per-message TTL matching the seconds until send time
const msUntilSend = scheduledAt.getTime() - Date.now();
await scheduleWithDelay({ type: "weekly-digest", userId }, msUntilSend);

Summary: Key Takeaways​

  • FIFO queues use linked lists or ring buffers — enqueue at tail, dequeue from head, both O(1). Fast at any depth. Head-of-line blocking is the main failure mode.
  • Acknowledgement is a three-state machine — READY → UNACKED → DELETED (or back to READY on nack+requeue). The broker keeps a message until the consumer explicitly acks it. This is what makes queues safe across crashes.
  • Persistence requires two settings — durable: true on the queue (the definition survives restart) and persistent: true on each message (the body survives restart). One without the other is a silent trap.
  • Priority queues use min-heaps — O(log n) insertion, constant extraction of the highest-priority item. Starvation of low-priority messages is the main failure mode.
  • Delay queues in RabbitMQ use TTL + DLX — no native delay without the plugin. Understand the pattern before using it in production.
  • Circular buffers intentionally overwrite — never use for durable job processing. Use for latest-N streaming data only.
  • DLQ is non-negotiable in production — without it, failed messages either loop forever (nack+requeue) or disappear silently (nack without requeue).
  • Push vs pull is the core difference between RabbitMQ and Kafka — push fits job queues; pull fits event streaming with independent consumer groups.

What's Next?​

You now understand how queues work from the data structure up — the linked list underneath FIFO, the state machine of acknowledgement, the write-ahead log that gives you persistence, the five queue types and their failure modes.

The next step is understanding RabbitMQ's specific routing model with exchanges and bindings — which add a layer above queues that lets producers route messages to the right queue without knowing it exists.

References​