---
title: "Ordering and deduplication"
description: "One partition per entity keeps each entity's messages in order while the global stream interleaves, and a repeated transactionId is refused rather than stored twice."
---

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

# Ordering and deduplication

This is the pair of properties Queen exists for.

The program pushes messages for three customers, interleaved, into one queue but one partition
per customer. When it reads them back, each customer's messages are in the order they were
pushed, even though the interleaving across customers is not the order anything was written. That
is what a partition buys: an ordered lane per entity, and a slow reader on one lane never holds up
another.

Then it pushes the same message a second time with the same \`transactionId\`. The broker answers
\`duplicate\` and stores nothing. The check happens inside the database, under the partition's own
lock, before an offset is allocated, so it is exact rather than best effort.

### JavaScript

### Python

### Go

## What to take away

Ordering is per partition and never global. If you need two messages to be ordered relative to
each other, they must share a partition, which usually means partitioning by the entity the
messages are about.

Deduplication is bounded by a window (one hour by default). Outside it, the same
\`transactionId\` is a new message again, so the window has to be longer than your longest
retry.

Next: [the transactional pipeline](/full-examples/pipeline).

Source: https://queenmq.com/full-examples/ordering-and-dedup/index.mdx