И мне кажется, что вам с таким кейсом не интегратор нужен, а кто-то вроде dataart

во-первых, 1 млн это не очень большое количество пользователей само по себе
во-вторых, технически важнее количество транзакций
в третьих, разделяйте слои: вы биллинг хотите модернизировать или платёжный шлюз всё-таки? Какую из частей "платёжной системы"? Или всю архитектуру перепилить? Тогда почему именно шина стала ключевым элементом? Старайтесь вообще логику и шину отдельно держать по-максимуму (100% ни у кого не получалось ещё)

ну и в чётвёртых, выбор-то не велик - либо модная кафка, либо проверенные IBM или Оракл
Вендоров не порекомендую: что белочка, что джет, что Ланит - все имеют свои плюсы и минусы

Я вот тут не силен, как это будет называться.
нам надо будет поставить шину, помочь нам с ее интеграцией (архитектурно ест-но), и. если требуется, обучение.

им вообще в последнюю очередь нужно думать о данных. Это транзакционная история.

Да, ест-но, хотим модернизировать шлюз, т.е. сделать подключение партнеров/поставщиков более простым иуниверсальным

партнёры насколько крупные\молодые?
Просто если больше энтерпрайза, то это больше склоняет в сторону оракла или IBM, если больше хипстеров, то меньше )

может, у вас вообще основной протокол для подключения - SMPP, а вам тут кафку суют )))

По транзакциям - тут есть местные ментальные особенности, первого чиста каждого месяца у всех отрубается интернет, связь и т.д.
никто не хочет платить заранее, поэтому первого числа проходит порядка 40% всех платежей за месяц :)))
Поэтому не стал углубляться, но, в целом, нормально так трясет в эти часы.

не-не :)))
По смпп только смс шлюз и то смпп наружу к опсосам. внутри - вызов хранимки через метод ( нжикс помойму сейчас)

есть вообще готовые решения шлюзов, беркут всякий. Тут смотреть надо

Да, я что-то такое, помню, встречал. Что-то тогда не устроило, уже не вспомню.

ну там очень проприетарно всё, такое сложно как-то приживить к себе в ландшафт с пользой, если сам не являешься огромным энтерпрайзом

Мы крупная логистическая компания. Объёмы транзакций не скажу (дсп, извините), но большие. Сидим на IBM. Замутили проект на kafka. Модно же, надо попробовать. В целом тянет, но по железу много тяжелее IBM. По моему опыту вывод такой: IBM дорогой софт, дорогие люди/интеграторы, очень разумно по оборудованию(заводится чуть ли не на ноутбуке) ; Kafka дорогое железо даже для минимальных нужд, но людей много и стоят копейки. Работает и то, и то. Если что не так, слезть больно и с того, и с того.

А что с кафкой дорого по железу? Там же копеечное всё

Она тормозная очень. Ну, на фоне IBM, как минимум. Объёмы давили увеличением аппаратных ресурсов. "так себе история" (с) .

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

Так а вы на nvme ssd писали? И сеть, надеюсь, хотя бы 10g?

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

Да. Вот мы и масштабировали. Я именно об этом. При том, что IIB справлялся без расширений.

... И справляется