hq/02-DECISIONS/0131-everything-on-the-mesh-speaks-to-the-broker-seat.md

topic, status, date, deciders, reconstructed, supersedes

topic	status	date	deciders	reconstructed	supersedes
the mesh	accepted	2026-09-27	jochen	false	0127-amqp-is-a-provision-not-the-bus.md

131. Everything on the mesh speaks to the broker seat, and AMQP is not a provision

Context

ADR 0127 settled the old broker as an ordinary provider of an ordinary provision, amqp, kept for whatever wanted a message broker of its own. The day the bus moved was the day that framing was tested, and it failed in a way that took the control plane down for an evening.

Three things came out of the wreckage. The protocol had leaked into the seat's contract: for a module to hold mesh-broker, it had to provide what the seat delivers, and what it delivered was amqp — so the module that will carry the bus on NATS could not hold the seat that names the bus, while the module the mesh was leaving could. A consumer of amqp is not asking for AMQP. The two modules requiring it wanted the mesh's messaging — to emit an event, to hear a topic — and named the wire protocol only because that was the word available. And AMQP and NATS are not interchangeable at the wire. A provision named after a protocol can only ever be answered by that protocol, so once the bus is NATS an amqp provision has one possible provider, and it is the thing being retired.

The operator's position, stated during the outage: modules depend on the broker seat, not on a protocol; AMQP is obsolete as anything the mesh's core knows about; a module that depends on amqp is wrong; and everything should reach the mesh's bus and be able to emit events and consume topics through it.

Decision

A module that needs messaging uses the mesh's bus, and the mesh's bus is whatever holds mesh-broker. Emitting an event and consuming a topic go through the sdk, which is handed the bus by the mesh with the module's own credential. No manifest names a wire protocol to get it.

amqp is neither a provision nor a requirement. Registration refuses a manifest that provides it or requires it. The mesh-broker seat delivers mesh-bus, and its holder is the module that provides mesh-bus — today the nats module, and only it.

The old broker's module and the two modules that required it leave the catalogue. They are removed, not converted: one was a proof that a grant worked end to end, the other forwards mail off a queue, and both are re-done against the bus if wanted, as new modules under this record.

The controller's AMQP transport is deleted once every node reports on the new bus, and the switch that selects a transport goes with it — one bus, so nothing to select.

The predecessor's own broker is outside the mesh and not this record's concern (ADR 0130): what the predecessor's tooling loses when it stops is accepted there.

Options considered

1. Keep 0127: AMQP stays an ordinary provision with the old broker as its provider. Rejected. It is what put the protocol into the seat's contract, it is why the seat could be left with no valid holder mid-change, and it keeps two transports in the control plane indefinitely for the benefit of two modules that did not want AMQP in the first place.
2. Bridge it: the old broker's module also provides mesh-bus, so both can hold the seat during the change. Rejected. It makes the retiring broker a legitimate mesh bus for exactly as long as nobody removes the line, which in practice is forever, and it leaves amqp as a thing the core still knows the name of.
3. The seat is the dependency; the protocol is nobody's business but the holder's. Adopted.

Consequences

• The change of holder is a handover, and it needs a command. Nothing today moves a seat from one assignment to another as one act, and a seat the control plane dereferences cannot be empty in between — that emptiness is the outage this record comes from. The command takes a seat and the assignment taking it over. Designed and built before the cutover, under 28 — Building the bus.
• The seat's row moves to mesh-bus before the new holder registers, and that is safe. The control plane composes its own bus address through the seat by name (${seat:mesh-broker:…}), and the overview derives holders by name; only registration and the provision-to-seat resolution read what a seat delivers. So the row can change under the current holder without unseating it, the new holder can then register its claim, and the handover happens when both are running. Verified in the code during the outage, not assumed.
• Registration gains two refusals: a manifest providing amqp, and one requiring it.
• The rollout check stops saying the old broker stays. It said so under 0127; it now lists unassigning it as the last step of the move.
• What got harder: a third party that genuinely wants an AMQP broker on a mesh node runs one as any application module, with no provision and no seat, and nothing on the mesh routes to it. That is the cost of the mesh not knowing the word.

How this is checked

Rule	Checked by
No manifest provides or requires amqp	a registration test refusing each, naming this record; and a whole-catalogue test asserting no registered manifest names it
mesh-broker delivers mesh-bus, and only a mesh-bus provider may hold it	the existing registration test for a delivering seat, with the row's value read from the store (mesh-controller#89)
The seat's row can change without unseating the holder	a test composing the control plane's own address and the overview under a row that the current holder does not satisfy
The rollout does not leave the old broker running	rollout check output, asserted in its test
The AMQP transport is gone	the package does not compile with it referenced; the switch variable is refused as unknown at start