How-to guide
Ordered delivery & per-key lanes
Some events must arrive in order — an order.updated can't overtake its order.created. Queuey controls ordering on two independent axes: how events are grouped and how strictly they're ordered within that group.
The two axes
| Axis | Options | What it controls |
|---|---|---|
| Partition | None · ByKey | Whether the queue is one stream (None) or split into independent lanes by a key (ByKey). |
| Ordering | BestEffort · Fifo | How strictly events are ordered within the scope — the whole queue (None) or each lane (ByKey). |
Whole-queue ordering
With Partition = None and Ordering = Fifo, the queue is a single ordered stream. A concurrency cap bounds how many deliveries run at once. Simple and strict — but one slow event holds up everything behind it.
Per-key lanes
With Partition = ByKey, each distinct key (e.g. an account, an order id, a customer) becomes its own independent lane, ordered within itself. Tune them with concurrencyPerKey and maxActiveKeys.
No head-of-line blocking across keys
A stuck event in customer A's lane never blocks customer B's lane — they advance independently. You get strict per-customer order and parallelism across customers. The lane key is derived from the event's context (see Customer context).
Related
- Customer context (GroupKey) — where the lane key comes from.
- Reliable delivery — retries and DLQ inside each lane.