Всем привет! Classic или quorum? Банковский софт. Через Реббит бегают онлайн

транзакции. Потерять данные после того, как кто-то приложил карточку для оплаты, как бы неприемлемо.

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

Нагрузка не слишком большая. Max TPS 10.000.

В общем какой тип очереди предпочтителен в моём случае? (с учётом кластеризации и репликации естественно)

Заранее спасибо за комментарии!

Я думаю что сама по сути транзакция должна быть синхронная. Надо как минимум проверить баланс и отклонить транзакцию в случае нехватки средств. Тут реббиту вообще не место. Но если речь о дальнейшей обработке событий, после совершения транзакции - то тут надо исходить из того что вам важнее, работа при выходе из строя 2 из 3 нод и производительность или кворумный арбитраж на каждое сообщение

Уточню. Это процессинг. По очередям бегают ISO сообщения от банка эквайера к банку эмитенту и обратно. Железо сверхсовременное: памяти 2тб, ядер то ли 128, то ли 256 (запамятовал). Важно не потерять данные пока они в процессе обработки бегают из очереди в очередь. В доках вычитал, что quorum для таких целей подходит больше. Но и потерять в скорости тоже не хотелось бы, т.к. каждое сообщение от эквайера проходит круг в 8 сервисов и 4 очереди между этими сервисами пока вернётся ответ эквайеру обратно.

Ну да, кворум тут значительн лучше подходит

Возмжно вам нужно будет просто шардировать между кластерами нагрузку