0041 — Azure Service Bus in all environments

Decided. Azure Service Bus is the only message broker. RabbitMQ has been removed. Locally, the Azure Service Bus emulator replaces it. This supersedes the RabbitMQ portion of 0004.

What changed

• common/transport.Transport now has one implementation: ServiceBusTransport. BUS_BACKEND is gone; there is no runtime switch.
• The local Docker Compose stack no longer includes a RabbitMQ container. The Azure Service Bus emulator (mcr.microsoft.com/azure-messaging/servicebus-emulator) runs in its place.
• Publisher tests use a no-op transport.Transport fake. Per-test vhost isolation and the amqp091-go dependency are gone.
• common/transport.Consumer provides queue receive for services that consume events.

Why

Operational parity. Running RabbitMQ locally while using Service Bus in Azure meant two code paths, two sets of credentials, and infrastructure differences that could mask bugs. The emulator gives the same API locally as Azure.

Simplicity. BUS_BACKEND required every service to branch at startup. Removing it removes a class of misconfiguration and cuts dead code paths.

One dependency. github.com/rabbitmq/amqp091-go is gone from go.mod. The Azure SDK (github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus) is the only broker client.

Alternatives considered

Keep RabbitMQ locally. Avoided because it diverges from production and requires maintaining two transport implementations indefinitely.

Keep both transports, default to Service Bus. Avoided for the same reason — the second transport decays if not exercised in CI.