RabbitMQ / Advanced: ordered ownership, retained replay and accepted recovery / Lesson 13

Single active consumer and key ordering

Choose an ownership boundary that preserves the required business sequence without confusing delivery order with effect completion.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain active and standby consumers under single-active-consumer behavior.
Review key partitioning, failover and asynchronous completion together.

State which operations require order

Parcel accepted and parcel dispatched may require a sequence for the same parcel, while unrelated parcels can progress independently. Name that invariant before selecting consumers. A queue’s ordered storage and delivery do not establish a global causal order across independent publishers or queues. Concurrent handlers can also finish in a different order from delivery. Priorities, requeue and failover complicate observed order further. If the destination rejects stale versions, that rule is another explicit part of correctness rather than an automatic broker feature. Choose the smallest serialization scope that matches the business requirement and make its throughput limit visible.

One active consumer still needs safe effects

Single active consumer permits registered consumers to stand by while one receives the queue’s deliveries under the supported queue-type behavior. When the active consumer disappears, another can become active. It differs from forbidding other subscriptions entirely through an exclusive-consumer choice. The active worker can still dispatch deliveries to a parallel local executor and reorder effects, so review its processing design. Unacknowledged work can be redelivered around failover; single ownership does not mean exactly-once execution. Queue declaration arguments and queue-type support must be checked for the selected version rather than assuming this feature can be toggled on any existing queue without migration.

Keep a declared key on one processing lane

The offline map assigns two parcel identifiers to two named lanes and verifies that repeated P17 work stays on its declared lane. It is a supplied application mapping, not a RabbitMQ consistent-hash plugin implementation or a routing test. A real keyed partitioning design needs deterministic serialization, stable mapping and a migration policy when lane count changes. Existing messages do not automatically move to preserve a new mapping. A hot parcel or tenant can still dominate its lane, and adding idle workers to other lanes does not divide that key’s required sequence. Measure skew separately from aggregate capacity.

python Offline declared key-to-lane mapping

lanes = {'P17': 'labels-a', 'P18': 'labels-b'}
work = ['P17', 'P18', 'P17']
routed = [lanes[key] for key in work]
assert routed == ['labels-a', 'labels-b', 'labels-a']
print(routed)

Expected output

['labels-a', 'labels-b', 'labels-a']

Both P17 items use labels-a; no exchange, plugin or consumer scheduler is exercised.

Review ownership and processing as one contract

The JSON fixture records a quorum-queue declaration intent with x-single-active-consumer and a separate application rule to process each lane serially. It is not a complete definitions document and is never imported. The broker option and the worker rule solve different parts of the ordering problem. A destination version check can provide another defense against stale writes, but its comparison and conflict behavior must match the event contract. Do not acknowledge an entire batch past unfinished work merely because only one consumer is active. Acknowledgment and external completion still need consistent accounting through shutdown and replacement.

json Synthetic ordered-lane design record

{"queue":"lab.labels-a","arguments":{"x-queue-type":"quorum","x-single-active-consumer":true},"application_processing":"serial-per-lane","preserve_operation_identity":true}

The queue arguments and application processing rule are separate requirements; no topology is declared.

Test order at the destination boundary

An authorized ordering test would include two updates to one key with unequal processing duration, an unrelated key, active-consumer replacement and a redelivered operation. Verify accepted destination versions and unique effects rather than only callback arrival order. This lesson creates no consumer or queue and performs no failover. Its local lane check establishes deterministic behavior for the supplied map only. Operational adoption also needs evidence of queue support, available standby capacity and recovery timing. Keep those untested platform properties separate from the small application invariant so a passing Python assertion is not presented as an ordering certification.

Common errors and fixes

One active consumer still writes parcel updates out of order.

Why it happens: Its internal parallel executor reorders effect completion.
How to fix it: Serialize the required key scope or enforce a destination version rule.
Prevent it next time: Test completion order with deliberately unequal work durations.

Changing lane count breaks an existing key sequence.

Why it happens: Old and new routing mappings were not migrated together.
How to fix it: Plan source coverage and ordering through the mapping transition.
Prevent it next time: Version the key mapping and its serialization contract.

Failover repeats an already applied operation.

Why it happens: The effect completed before its acknowledgment became certain.
How to fix it: Use stable identity and duplicate-safe destination application.
Prevent it next time: Include redelivery in the ordered-processing acceptance plan.

Check your understanding

1. Does single active consumer prevent a local thread pool from finishing the second delivery first?

Show worked solution

No. It controls the active broker subscription, not every downstream scheduling decision. The worker must preserve the required sequence or the destination must reject stale versions under a reviewed rule. Keep callback arrival order, processing completion and acknowledgment order as separate observable milestones.

2. Why is the supplied lanes dictionary not evidence that a consistent-hash exchange is installed?