---
title: "Transactional pipeline"
description: "Acknowledge the input and push the next stage's message in a single database transaction, then watch a failed message be redelivered instead of lost."
---

> Documentation Index
> Fetch the complete documentation index at: https://queenmq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Transactional pipeline

The previous two examples each used one queue. Real systems chain them, and the chaining is where
messages usually get lost.

This program consumes from an orders queue and, for each message, acknowledges the input and
pushes a derived message to an invoices queue **in one transaction**. Either both happen or
neither does. There is no window in which the input is acknowledged but the derived message was
never written, which is the failure that silently drops work in most queue systems.

It then acknowledges one message as failed, and shows it coming back rather than disappearing.

### JavaScript

### Python

### Go

## What to take away

The transaction is one PostgreSQL transaction, which is exactly as strong as that sounds and no
stronger. It does not make the pipeline exactly-once end to end: if the response is lost and the
client retries, the push happens again. Making that safe is the job of a deterministic
\`transactionId\` and the deduplication window from the previous example.

A nack costs a retry from the message's budget. When the budget runs out the message goes to the
dead-letter queue rather than round the loop forever, and you read it there with
\`GET /api/v1/dlq\`.

Source: https://queenmq.com/full-examples/pipeline/index.mdx