Всегда ли нужен брокер сообщений?

Другой кейс - реальный, из опыта одного из наших клиентов.

Компания онлайн и офлайн торгует бытовой химией, пищевыми добавками, товарами для здоровья.

Некоторые заказы оформляются через интернет-магазин, другие - через продавцов или торговых представителей в филиалах.

Бонусная система для офлайн-покупателей привязана к сочетанию ФИО и контактных данных.

Но случались такие ситуации: когда кнопка «подтвердить» нажата, покупатель мог вспомнить, что с последнего визита у него изменился номер телефона.

Приходилось переоформлять заказ с тем же составом продуктов, тем же ФИО покупателя, но новым телефоном. В итоге брокер передавал в CRM-систему оба заказа, вычищать дубликаты из каждой системы приходилось вручную. Кейс, который мы описали, - не единственный известный нам подобный случай.

При использовании брокера дубликаты сообщений приходят в конечные системы достаточно часто. И чтобы от них избавляться, приходится: или вычищать дубликаты вручную; или прописывать в системе-получателе дополнительную логику - например, система должна находить дубликаты по ключевым параметрам, сверять время отправки, убирать более ранние записи и оставлять только более новые сообщения.

А ведь иногда вам нужно делать сложную выборку для внешних потребителей, и тут брокер почти бесполезен.

Снова представим кейс. В вашей PIM-системе хранятся карточки товаров: тех, которые есть у вас в ассортименте сейчас, и тех, которые временно не продаются.

Не продаются, потому что вы только их закупаете, или это сезонные товары, или пока нет поставок - вариантов множество.

Но маркетплейсу нужно от вас получать: товары, которые есть в наличии на складе, с пометкой «есть в наличии»; те, которые поступят в ближайшее время - тоже с соответствующей пометкой; те, которые скоро кончатся и вы не планируете их докупать, - со статусом «скоро закончатся».

Чтобы сделать такие потоки данных, надо прочитать несколько источников, сравнить их, объединить и только потом отправить.

Чтобы реализовать такую логику с брокером, придётся на стороне PIM-системы, WMS-системы, системы управления закупками (и, возможно, еще пары систем, которые связаны с продажами) кодом прописать ограничения для выгрузки на маркетплейс.

При большом ассортименте и сложном каталоге вам придётся или подстраивать время выгрузки на неактивные часы пользования системами, или мириться с «тормозами», которые захватят ключевые части вашей ИТ-архитектуры.

При использовании связки из базы данных + ETL вся логика переходит на слой коннекторов, не замедляя ни одну из систем-источников.

Кажется, что брокер может подойти в процессах, в которых нет сложной логики и важна максимальная скорость передачи.

Но и в этих случаях не всегда именно брокер является лучшим решением. Например, на одном из наших проектов скорость была ключевой метрикой: записей было не так много, но их статус постоянно менялся.

Мы обеспечили постоянное обновление статусов с помощью брокера, но системы-получатели просто не успевали обрабатывать поток поступающих сообщений с обновлениями.

Как это ни парадоксально, именно обновления (то, что менялось чаще всего) системам-потребителям не были нужны.

Их интересовали только сами записи.

Как результат, лучшую скорость обеспечила пакетная обработка из реляционной базы данных: она не перегружала системы-получатели и доставляла в них все необходимые данные.