Kraken moved its Celery queues to a new vhost before touching RabbitMQ 4

Divide 8,000,000 by 86,400 and the average load is about 93 messages a second ^[15]. One broker node handles that without complaint. Throughput is not the wall. The wall is that RabbitMQ will not change a queue's type after the queue exists ^[5], and Kraken's SLAs do not allow the delete-and-recreate window that would normally follow ^[6].

The two removals in 4.2.2 point at the same target ^[2]. Losing classic queue mirroring forces the move to quorum queues ^[4]. Losing global QoS means a task carrying an ETA holds its worker until the ETA arrives ^[3], which is the opposite of offloading work. Celery's answer, Native Delayed Delivery, only runs on quorum queues bound to topic exchanges ^[7]. So the thing that breaks delayed tasks and the thing that forces the queue rewrite are both satisfied by one topology.

The flag that carries the migration is a single function. `build_queue` reads `USE_QUORUM_QUEUES` and flips two things at once: the `x-queue-type` queue argument, and the exchange type from `direct` to `topic` ^[9]. In the published snippet the exchange is also named after the queue type, so a pod with the flag off publishes to an exchange called `classic` and a pod with the flag on publishes to one called `quorum` ^[10]. Names chosen during a migration tend to outlive it. That naming is also the proof that this is a topology change and not a setting: two shapes of the application can run side by side, which is why a Kubernetes rolling update could leave some pods on the old vhost and some on the new one without harm ^[11].

Shovel was the obvious tool for moving the backlog between vhosts, and it was rejected for a precise reason: it copies messages as-is, `eta` header included ^[12]. Those messages would land in quorum queues still carrying the field that blocks a worker. The transfer therefore had to do what Celery does internally, popping the `eta` header, computing the delay-based routing key, and publishing to the matching exchange ^[13], with pika consuming and kombu's `native_delayed_delivery` helpers deriving the routing ^[14].

Whether that plan transfers to your system depends on three conditions the post makes visible. ETA or countdown has to be in real use, since that is where global QoS removal bites ^[3]. Two vhosts have to be able to run against the same broker for the length of the migration ^[8]. And a mixed fleet has to be acceptable, because the split between old and new pods is the mechanism rather than a side effect ^[11]. Shops that can take a maintenance window can delete and redeclare their queues and skip all of it.

The broker upgrade is the last phase ^[17]. Everything expensive happens while still on 3.13.7.1 ^[1]: provision `qhost`, teach the app both queue types, transform the backlog across, decommission `chost` ^[8]. By the time the version number changes, the old vhost holds nothing that could break.