Один кладёт JSON в тему, другой забирает. Никто никому не звонит напрямую, ничего не теряется, и всегда видно, что кому уходило.
Пятый сервис добавляет не одну связку, а четыре. Каждая — код с обеих сторон, свой формат, своя логика повторов. Когда рвётся, первый вопрос всегда один: чья сторона виновата.
Отправитель не выбирает получателя. Понадобился ещё один потребитель — ему заводят подписку, и его код никак не касается того, кто отправляет.
«Что заказ №12345 ушёл в 14:32 и получил ли это биллинг» — один запрос вместо сопоставления логов двух систем.
Потребитель лежал два часа — сообщения дождались его в очереди. Упал посреди обработки — вернутся сами.
Выкатили баг и обработали неправильно — сообщения перепроигрываются с нужного момента. Они никуда не делись.
Неудачное сообщение повторяется с растущей паузой, а потом уезжает в отдельный разбор — с причиной и телом, а не «где-то потерялось».
Ни библиотеки, ни драйвера, ни клиента под язык. Если ваш код умеет делать POST — он уже умеет работать с шиной. 1С, PHP, Python, Java, bash — разницы нет.
POST /topics/orders.created/messages
Authorization: Bearer …
Idempotency-Key: order-12345
{"orderId": 12345, "sum": 990.00}
Ключ идемпотентности — чтобы повтор при обрыве сети не создал второй заказ.
GET /subscriptions/billing/pull?wait=30 POST /subscriptions/billing/ack
Запрос сам ждёт появления сообщения. Не подтвердили — оно вернётся в очередь, а не исчезнет. Или наоборот: шина сама постучится к вам вебхуком с подписью.
Заводится тема — например, orders.created, — и подписка на каждого,
кто будет это читать.
Отдельный на сервис и с узкими правами: отправителю — только публикация в свою тему, получателю — только его подписка.
Отправьте тестовое и посмотрите в веб-интерфейсе, как оно прошло по очереди. Дальше — по инструкции: там готовый код продюсера и потребителя, проверка подписи вебхука и чек-лист интеграции. Описание всех запросов — в спецификации OpenAPI, её можно импортировать в Postman.
Чтобы не выяснять это в бою: