The comment on the ack line is the whole delivery-semantics table compressed into one statement: the position of your ack relative to your side effect is the choice between at-most-once and at-least-once. Nothing else about the broker configuration matters as much as that ordering.

---

A Dead-Letter Queue Nobody Monitors Is a Silent Data-Loss Queue

A message that fails repeatedly cannot be retried forever. After N attempts, the broker moves it to a dead-letter queue — a separate queue holding messages that could not be processed, with their failure metadata.

The DLQ is genuinely valuable. It stops one bad message from consuming your consumer capacity indefinitely, it preserves the payload so you can inspect and replay it, and it converts "this job keeps failing" from a log-grep exercise into a queryable set.

And it is the single most common place I see engineered data loss, for a reason that has nothing to do with the technology: the DLQ is a queue with no consumer. Messages arrive. Nothing reads them. Retention expires — often 4 to 14 days depending on the broker's configured maximum — and they are deleted. The system reported no errors, because moving a message to the DLQ is the successful completion of the retry policy.

So the operational rule, and treat it as non-negotiable:

• Alert on DLQ depth greater than zero, not on a threshold. A threshold implies some number of permanently failed business operations is acceptable, and if that is genuinely true for this queue you should be discarding rather than dead-lettering.
• Own the redrive. Someone must be able to inspect a dead-lettered message, decide whether the cause was transient or a bug, and replay it back to the source queue after the fix. If replay requires writing a script during an incident, it will not happen.
• Never point a DLQ at another DLQ, and never wire a consumer that automatically redrives on a timer. That is an infinite retry loop with extra steps and a bigger bill.
• Record why. The exception, the attempt count, and the consumer version. A DLQ full of payloads with no failure reason is an archive, not a tool.

Why this matters in production: with a DLQ that has an alert and an owner, a poison message is a ticket. Without one, it is a quiet subtraction from your data that surfaces months later as an unreconcilable total — and by then the payload has been deleted, so you cannot even determine what was lost.

---

Ordering and Parallelism Are the Same Dial

The uncomfortable structural fact about queues: you can have ordered processing, or you can have parallel consumers, and the amount you get of one is the amount you give up of the other.

The reason is mechanical. Ordering means message n must complete before message n+1 starts. That is a serial constraint. Parallelism means multiple messages in flight simultaneously. A standard queue with ten consumers gives you a tenfold throughput increase and no ordering guarantee whatsoever — messages can and will be processed out of sequence, and a retry reorders things further, since a failed message returns to the queue behind messages that arrived after it.

FIFO queues resolve this by scoping the ordering guarantee. You attach a message group ID to each message, and the broker guarantees:

• Messages within the same group are delivered in order, one in flight at a time.
• Different groups proceed independently and in parallel.

So the group ID is the dial. Choose it and you have chosen your ordering/parallelism trade-off:

Per-entity is almost always the right answer, because the business requirement is almost never "global order". It is "do not apply this account's debit before its credit" or "do not process document v2 before v1". Those are per-key constraints, and scoping the group ID to the key gives you exactly the ordering you need and parallelism everywhere else.

Two costs to name explicitly:

Head-of-line blocking within a group. One message that keeps failing blocks every subsequent message in its group until it is retried out or dead-lettered. With per-account grouping, one broken account stalls that account only — which is the argument for fine-grained groups. With a single group, it stalls the business.

Ordering does not survive your handler. The broker delivers in order; if your handler acks and then hands work to a thread pool, an await-free background task, or another queue, you have discarded the guarantee downstream. Ordering is end-to-end or it is decorative.

If your requirement is durable, replayable, partition-ordered streams rather than a work queue — many independent consumer groups reading the same ordered log at their own pace — you want a log, not a queue. That is Module P-15.

---

Poison Messages, and Where Backoff Belongs

A poison message is one that will never succeed no matter how many times you retry: a malformed payload that throws on parse, a reference to a row that was deleted, a schema version the consumer does not understand, a job whose target account was closed. The defining property is that the failure is deterministic.

The reason poison messages deserve their own name is that the default retry configuration treats them as transient, and a message retried every few seconds forever is a self-inflicted denial of service on your own consumers. Ten poison messages in a queue with a 1-second retry delay is ten requests per second of pure waste, competing for the same consumer slots as real work, for as long as retention allows.

The fix is to classify the failure before deciding the retry policy — which is Module F-8's retryable-versus-terminal error shape, applied to consumers:

• Terminal failures (validation error, unknown message type, referenced entity permanently gone) should go straight to the DLQ on the first attempt. Retrying a JSON.parse failure is superstition.
• Transient failures (dependency timeout, 503, connection reset, lock contention) should retry with exponential backoff and jitter — Module A-6's mechanism, and the queue is the ideal place for it, because the delay costs you nothing: the message waits in durable storage rather than a sleeping process holding a connection.
• Rate-limit responses (429 with Retry-After) should respect the header rather than the backoff schedule, and ideally slow the whole consumer rather than just that message, or you will spend your entire quota on retries.

Backoff interacts with queues in one way worth stating because it surprises people: backoff moves the retry into the future, which means your queue depth stops being a measure of pending work and becomes a measure of pending work plus scheduled work. A broker with per-message delay or a run_after column keeps these distinguishable. A broker without it, where you implement backoff by re-enqueueing with a delay, makes your depth metric noisier — which matters for the next section.

The other interaction is with maxReceiveCount. Exponential backoff with a base of 2 reaches long delays quickly, so a 5-attempt policy with a 30-second base spans roughly eight minutes, while a 10-attempt policy spans hours. Pick the attempt count against how long you are willing to leave the work undone, not by whether the number looks generous.

---

Queue Depth Is Your Earliest Honest Saturation Signal

This is the operational payoff of the whole module, and it is why queues are worth instrumenting well.

Latency and error rate are lagging indicators. By the time p99 has risen, the system is already degraded and users are already affected. CPU is misleading, because a consumer waiting on I/O is idle while being completely saturated in the sense that matters (Module F-4's utilisation curve is about the busy fraction of the bottleneck resource, which is rarely the CPU).

Queue depth leads. Specifically, the derivative does:

• Depth flat and low. Consumers are keeping up. Fine.
• Depth flat and high. Consumers are keeping up now, but you are permanently one incident behind — there is a persistent backlog absorbing your headroom.
• Depth rising monotonically. Arrival rate exceeds service rate. This is not a spike, it is a deficit, and it will not resolve on its own. Nothing about the request path has broken yet, and it will.
• Oldest-message age rising while depth is flat. Head-of-line blocking, or a starved message group. Depth alone hides this, which is why you alert on age of the oldest unacked message, not only on count.

That last metric is the honest one, because it is expressed in the unit the business cares about: how stale is the most delayed piece of work. "12,000 messages queued" means nothing without a service rate. "Oldest message is 40 minutes old" means the customer who ordered 40 minutes ago has no confirmation.

Little's Law from Module F-4 turns depth into a forecast directly. With arrival rate λ and total service capacity μ, a backlog L drains in roughly L / (μ − λ) — and if λ ≥ μ the answer is "never", which is the number you want on a dashboard during an incident.

What you do when depth rises is Module A-8's subject — backpressure and load shedding, including the genuinely hard question of whether to reject new work at the producer to protect the consumers. The queue-specific version of that decision: a queue with unbounded depth has converted a fast failure into an unbounded latency, and unbounded latency is often worse for the user than a clear rejection. Bounded queues that reject on full are an honest design, not a limitation.

---

When Postgres Is Genuinely the Right Queue

Module F-14 made the one-system argument: every additional datastore is another thing to operate, monitor, back up, secure, upgrade, and page someone about at 3am, and that cost is paid continuously while the benefit is often speculative. Queues are where this argument has the most teeth, because Postgres has a genuinely good queue primitive.

Three things to notice. SKIP LOCKED is what makes this scale past one worker — without it, ten workers all take a lock on the same oldest row and nine of them wait, serialising your entire fleet. leased_until is you implementing visibility timeout manually, which means a sweeper query that returns expired leases to ready is now your responsibility. And run_after is where backoff and scheduled retries live, which keeps them queryable in a way a broker's opaque delay does not.

Postgres is the right queue when:

• Throughput is within its envelope. Each claim-and-complete cycle is a couple of committed writes, and Postgres does roughly 1K–5K TPS with fsync-on-commit, so a job queue in the low hundreds per second is comfortable and a few thousand per second is a tuning project.
• You need the enqueue to be transactional with a business write. This is the strongest reason. INSERT INTO orders and INSERT INTO jobs in one transaction has no dual-write problem, no outbox relay, and no window where one committed and the other did not. Getting this property with an external broker requires Module A-3's machinery.
• You want to query your queue. "How many jobs for tenant 42 are pending", "show me every failed payout job from Tuesday", "cancel all jobs for this deleted account" are one SELECT each. Most brokers cannot answer any of them.
• The team is small and already operates Postgres well. One system you understand deeply beats two you understand adequately.

Postgres is the wrong queue when:

• You need high fan-out or pub/sub. Many independent consumer groups reading the same messages at their own offsets is a log's job (Module P-15), and simulating it with per-consumer job rows multiplies your write volume by the number of consumers.
• Throughput is genuinely high. Tens of thousands of messages per second means tens of thousands of row updates per second on one hot table, plus the MVCC consequence from Module F-13: every claim is an UPDATE, every UPDATE is a dead tuple, and a high-churn queue table bloats fast enough that autovacuum tuning becomes a standing chore.
• Retention or replay matters. Keeping seven days of processed messages for replay means a large, ever-growing table competing for cache with your live data.
• You would be reimplementing the broker. Visibility timeouts, DLQs, backoff scheduling, priority, delayed delivery, metrics, and a sweeper are each 20 lines and collectively a product. If you find yourself building the sixth feature, the one-system argument has stopped applying — you now operate two queue systems, and one of them is yours.
• Consumers hold connections while polling. Naive polling with a 100ms interval across 50 workers is 500 queries/s of pure overhead; LISTEN/NOTIFY fixes the latency but each listening connection is a forked backend process (Module F-13), which interacts badly with Module P-4's pool arithmetic.

The honest summary: for most applications' background work, Postgres with SKIP LOCKED is the correct first choice, and the migration to a dedicated broker is a decision you make when a named constraint above starts binding — not in advance.

---

Where This Shows Up in Your Stack

• PostgreSQL: SELECT ... FOR UPDATE SKIP LOCKED for the claim, a leased_until sweeper for expired leases, run_after for backoff and scheduled work, and a partial index on (run_after) WHERE state = 'ready' so the claim query never scans completed rows. Watch dead tuples on the jobs table — it is the most write-churned table you will own.
• Node.js: the consumer is a long-lived process, so it needs an explicit shutdown path: stop fetching on SIGTERM, finish in-flight messages, then exit — otherwise every deploy converts in-flight work into redeliveries. Concurrency per consumer must be bounded against the database pool (Module P-4), because 200 concurrent handlers and 20 connections is pool exhaustion with extra steps.
• Redis: Streams with consumer groups give you group semantics, per-consumer pending-entry lists, and XAUTOCLAIM for lease recovery at 100K+ ops/s. The cost is that durability is your configuration decision — an unreplicated instance with default persistence can lose acknowledged messages on failure, which is fine for cache warming and not fine for payments.
• SQS / Cloud Pub/Sub: managed durability and effectively unlimited depth, so the operational failure mode shifts from "the broker fell over" to "nobody noticed the DLQ" and "egress and request costs scaled with our retry policy" (Module O-8). Long polling instead of tight polling loops; it is both faster and cheaper.

---

Summary

• A queue buys decoupling, load levelling, and durable retries — and costs you end-to-end visibility, unbounded worst-case latency, and a second execution environment to operate and observe.
• Durable enqueue before responding is the only safe way to do post-response work, which is the mechanism Module F-10's "no work after the response returns" rule was waiting for. Enqueue in the same transaction as the business write, or you have recreated Module F-14's dual-write problem.
• At-most-once means ack first; at-least-once means ack after the effect is durable. The position of the ack is the entire choice.
• Exactly-once delivery is impossible because the acknowledgement is itself a losable message. Exactly-once processing is achievable through idempotency, and Module P-16 makes the full argument.
• Visibility timeout is a lease, not a lock. A handler slower than its lease gets redelivered and runs twice concurrently — the classic bug, and it correlates with incidents because that is when handlers are slow. Calibrate from measured p99, heartbeat the lease, and make the handler idempotent anyway.
• A DLQ nobody monitors is a silent data-loss queue. Alert on depth greater than zero, give it an owner and a rehearsed redrive path, and record the failure reason — dead-lettering is the successful completion of your retry policy, so it produces no errors.
• Ordering and parallelism are the same dial. Message group IDs scope the guarantee; per-entity grouping gives the ordering you actually needed with parallelism everywhere else, at the cost of head-of-line blocking within a hot group. Ordering is end-to-end or it is decorative.
• Classify failures before retrying. Terminal failures go to the DLQ on attempt one; transient failures get Module A-6's exponential backoff with jitter, which is nearly free in a queue because the message waits in storage rather than in a sleeping process.
• Queue depth, and especially oldest-message age, is the earliest honest saturation signal — leading where latency and error rate lag. Little's Law turns backlog into a drain-time estimate; λ ≥ μ means "never". What to do about it is Module A-8.
• Postgres with SKIP LOCKED is genuinely the right queue for transactional enqueue, queryable state, and moderate throughput — and the wrong one for fan-out, replay, very high throughput, or when you notice you are building the sixth broker feature yourself.

The next module, Event Streaming with Kafka, takes the one guarantee this module could not give you — that a message survives being consumed, so many independent consumers can read the same ordered history at their own pace — and shows what it costs: partitions as the unit of both ordering and parallelism, consumer group rebalancing, and offsets as the consumer's own state rather than the broker's.

---