FIFO + dedup

Two independent features, usually paired.

fifo_group — per-key ordering

Messages with the same fifo_group are delivered strictly in the order they were enqueued. Across different groups, delivery is concurrent.

await q.send("orders", payload, { fifoGroup: "user-42" })

All user-42 messages serialize. user-43 messages are independent.

Within a fifo_group, a second send with the same dedupe_id inside 5 minutes is rejected. Server returns 200 with deduped: true.

await q.send("orders", payload, {
  fifoGroup: "user-42",
  dedupeId: "order-9001",
})

dedupe_id requires fifo_group. Otherwise 400.
dedupe_id + delay → 400. Pick one.
Just want retry safety? Use Idempotency-Key instead — 24h window, no fifo_group required.

Feature	Idempotency-Key	dedupe_id
Window	24 h	5 min
Needs fifo_group	no	yes
Works with delay	yes	no
Semantics	SDK retry safety	Producer-side dedup per business key

Idempotency-Key for “my network flaked, safe to retry”. dedupe_id when you have a natural business key you want BOTH serialized AND dedup’d.

FIFO groups don’t slow you down — different groups still fan out across all consumers.
A single hot fifo_group IS serialized on the consumer side. If user-42 ships 10,000 messages in a minute, they run one-at-a-time.