Да уж... Сколько по времени лет Oracle "отлаживал" ASM Tuning? И только в последних версиях (начиная с 19) он стал работать более менее адекватно... Какой "самонастраивающийся механизм" знает что завтра у вас будет обновление прикладного приложения с введением нового функционала и измененным "профилем нагрузки", или что "завтра" вы будете делать upgrade версии DB с "улучшенным функционалом"? Может "самонастраивающийся механизм" (до запуска пользователем "тяжелой для БД" прикладной процедуры) распределить ресурсы/нагрузку между множеством пользователей/процессов в БД "по желанию" администратора ("сегодня так а завтра по другому"), поскольку общая нагрузка не постоянна "по времени"? Может "самонастраивающаяся БД" знать, что завтра у вас количество пользователей или клиентов прикладного приложения увеличиться на 30% (поскольку с завтрашнего дня у вас новый клиент или договоры)? Просто "посмотрите" на "самонастраивающиеся" виртуальные сервера, у которых "регуляторов" по сути менее 20 (причем всего 4 типов CPU, RAM, IO диск и сеть), и сравните с современными БД (регуляторы которых "в прямую" зависят от ресурсов OS)...
Ну как бы конкретную DB в любом случае нужно подстраивать/оптимизировать под специфику прикладного приложения (с учетом доступных ресурсов и профиля нагрузки на нее) и это задача DBA... Другой вопрос что прикладное приложение должно "учитывать особенности реализации конкретной DB", а это сейчас большая проблема для современных прикладных разработчиков которые "по факту" только сторонними фреймворками и умеют пользоваться...
:-) Если в прикладной обработке на Oracle использовались множественные SELECT + UPDATE (и это "прокатывало", причем это конечно "скрыто" внутри GetObject(a) + SetObjectProperty(b) ), то на PG получаем "проблемы производительности"....
Полностью согласен... Принципы реализации многих "базовых" функций БД в Oracle и PG различные. Если прикладной софт, прикладные разработчики это "не учитывают" - при миграции приложения получите "как минимум" значительное падение прикладной производительности. Особенно на OLTP прикладных системах...
:-) Если пользователь четко не определил что он "хочет" (хоть на определенном этапе работы, хоть на весь финальный "заказ") - объем "бесполезной" работы исполнителя будет абсолютно одинаковый....
"Скрам нужен, когда вы понимаете что хотите, но не понимаете как достичь. И тут с помощью инкремента вы ищите свой путь " - а "потом" "вдруг" выясняется что ваше "понимание" (и проделанная вами работа) скажем так - не совпадает с пониманием целей и "хотелок" заказчика... :-)
:-) Я бы добавил так... У них в голове "объекты"... Ну понятно что для объекта проще всего сделать GetObject(i) -> SetObjectProperties(j) -> WriteObject(i).... А то что "за этим" стоит в БД им как бы "фиолетово"... И "получается" что вместо "update table set prop=x where id=i" в БД "получаем" select * from table where id=i (и это еще хорошо что в одной таблице, а могут выбирать все "свойства объекта" и из 10 по разным связкам + штук 5 "справочников") + зачастую могут выбирать и с блокировкой строк эксклюзивной и "подождать" реакции пользователя или удаленного сервиса с минуту + update (и хорошо если в одной таблице), а то могут обновить данные в нескольких связанных (ну вот такая у них "модель данных хранения").... И все это у них называется "объектное программирование".... :-)
:-) Забудем на минуту "тонкие и сложные нанометры" и вспомним "добрым словом" "отечественный" легковой автопром... Как там соотношение между "хорошо и дорого"? :-) А вроде и технологии все не заоблачно сложные....
Про "выглядит" ничего не могу сказать... Могу прокомментировать только про "звучит"... Железо соответствует минимально необходимому на текущий момент для подобных устройств (процессор и оперативка). Разнообразные китайские аналоги в рознице с подобными характеристиками CPU и флеш (но 4GB RAM что предпочтительней, т.к. работа приставки будет более "живой") дешевле на 1000 рублей (20%)... Так чем же хочет привлечь покупателей поставщик такого устройства? Жесткой привязкой к своей "экосистеме"? :-)
Это полная чушь... Невозможно отключить то что не имеет доступа в сеть... Ну а если вы его предоставили - значит не читали описание и условия взлома лицензии.
:-) У каждого свой реальный опыт и кругозор... Отказ "сайта банка" несет "немного" другие последствия, чем отказ центрального процессинга целой страны или платежной системы банка с 50 млн. активных клиентов и гигантской эквайринговой сети...
"Появлись много noSQL решений, которые в обмен на рпотерю "крутой" транзакционности дали скорострельность, гибкость и все такое." - именно "все такое" но не ACID.... Тут "главный критерий", а кто будет "расплачиваться" при "потере" нескольких млн. $ + репутации, когда "замечательные" решения "потеряют" финансовые транзакции? :-) Опять видны "уши" agile - "будем решать проблемы по мере их поступления" У людей постоянно занимающихся тестами на производительность и устойчивость высокопроизводительных технологических OLTP решений (включая кластеризацию, виртуализацию, контейнеризацию, шардирование баз на разных уровнях) - "есть другое мнение", чем у "теоретиков" начитавшихся маркетинговой чуши.
"Я думаю, очевидно, что крутится в контейнере, а что - нет." - я тоже... :-) И не очень понял как контейнеры относятся к нашему предмету обсуждения - "работы OLTP БД".... Что касается "нарезать" сразу - то пару раз в году (на праздники) нагрузка на БД и приложение раза в 3 выше чем остальные 360 дней. Будете "резать" с этим учетом? А под StandBy и DRS еще "нарезать" (с учетом что StandBy без нагрузки раза в 2-3 требует меньше ресурсов)? Очень экономно... А под пару периодических нагрузочных тестовых систем (плюс с десяток под функциональные тесты) - еще ресурсов "заранее нарезать"? Я уж про межкластерные сетевые требования и задержки (при отсутствии специализированных шин обмена) и не говорю... :-)
Да-уж... DML транзакции БД выполняются всегда "последовательно" (см. SCN). :-) "Набирайте" сколько хотите пока не случится такое - https://habr.com/ru/news/800851/ У вас в контейнере БД работает? :-) "Я не настолько богатый, чтобы покупать дешевые решения..." :-)
1) "Проверка 3DS может является частью этого шага" - не является... 3DS проверка это опциональный шаг выполняемый до авторизации. 2) "между которыми 10 может быть до 10 секунд" - именно может, а не всегда проходит (по факту "в среднем" 1,5 секунды отдельные пики до 2, 2-10 только штучные на периоде в сутки). 3) "иногда не только" - всегда поскольку это принцип работы OS с памятью на любых платформах. 4) На LPAR вы динамически (и даже автоматически на уровне виртуализации) можете "распределить" все ресурсы (и CPU и память и IO). На других платформах "в ручную" так же (HP,Oracle). Но только IBM это делает без "фриза" всей OS (и ее процессов) под нагрузкой на момент изменения количества CPU и RAM. Тесты были на всем (включая Exadata, HP UX и т.п. решениях). Если есть у вас возможность проверить - можете убедиться. :-) Что касаемо Exadata то для прикладных OLTP систем она "особо" не лучше любых навороченных Enterprise систем. Единственное ее неоспоримое преимущество - один вендор при использовании Oracle DB.
Еще раз... 3DS проверка - отдельная процедура и не имеет отношения к обработке карточной операции. Точнее имеет (поскольку использует параметры карточной) но выполняется "независимо" и завершается до процесса авторизации (а вот он уже использует ее данные). Если в транзакции вы используете select for update то - блокировка длится до commit/rollback. Причем тут 10 секунд? 10 секунд это допустимый максимум ответа, а не постоянная величина.... Лочится не "строка" - а "блок данных" (там и N строк м.б.) причем в памяти... Впрочем от IBM и ее технологий мы уже "ушли далеко". Но... Только на IBM P тот же Oracle без "пауз в работе БД" ("провалов" TPS) позволял менять количество доступных OS виртуальных ядер (ни одна платформа этого не позволяет) и только IBM динамически может перераспределять общие/единые ресурсы между виртуальными машинами.
3DS - это не про финансы... Это тупо проверка что "клиент реально твой" и идет "на стороне издателя". Ее результат тупо "пристегивается" к запросу операции. :-) Если все "в одной транзакции" - БД рулит корректным состоянием данных. На 2 шаге проверяется что текущий баланс минус сумма самой операции более 0. И поскольку последовательный "порядок" операций контролируется БД (а "по другому" ни одна ACID БД не работает), то все будет OK нужная сумма "будет всегда" и "отрицательный" ответ авторизации не изменит баланс. Учите теорию баз. "Проблемы" возникают только с блокировками в данном случае. А вот вариант "уменьшить" блокировки путем "деления" на две транзакции - и приводит к описанным вами "проблемам" - через 10 секунд "порядок" исполнения меняется (баланс м.б. не таким как при первой транзакции проверки баланса). И вот тут реально и начинается "отдельная песня". С дополнительными "искусственными" транзакциями/операциями отмены/корректировки и т.п. Читайте свои "тонны книг", но согласно математике 2+2 равно 4, а не "5 если продаем и 3 если покупаем" - как вы предлагаете. :-) Любые "авторизации" + "подтверждения" еще более нагружают и усложняют систему. Любые взаимодействия с "внешними" сервисами/"прокладками" увеличивают время "блокировки" или меняют "исходный" порядок операций. И мы пока еще даже "не касались" "проблем устойчивости и надежности" всей системы "в целом"... :-)
Вы просто реально "не в теме", мое описание процесса содержит хорошо если 10% бизнес условий (скажем так "самое узкое место"). Очень сильно напоминает ajile подход - " Видим путь в тумане только на 5 метров в одном направлении, но все равно бежим туда, может и добежим в конечную точку, а может нет..." Вы же как "архитектор" не разбираясь до конца в сути уже начинаете предлагать конкретные решения. :-) Почему именно kafka, почему именно redis? "Стильно, модно, молодежно?" Как то блокчейна не хватает и IA... :-) Что значит "строго последовательно" 10 операций поступили извне в одну и ту же милисекунду, где тут последовательность? "Последовательность транзакций/операций" может только на уровне БД или единой очереди "возникнуть".... И еще раз - последовательность поступления карточных операций по времени <> последовательности взаимодействия этих операций с балансом единого счета + между временем поступления карточной операции и временем ее взаимодействия с балансом единого счета может пройти до 10 секунд. Опять же очень сильно упрощенно, по основным шагам и при положительных проверках, в одной БД транзакции получаем -
Внешний входящий запрос на карточную операцию в БД (по сути insert операции).
Проверка единого баланса издателя на допустимость операции к исполнению (по сути select баланса)
Отправка запроса на одобрение издателю карт (по сути update операции)
Проверка таймаута ответа (10 секунд)
Получение авторизации/одобрения издателем (по сути update операции)
Дебетование единого баланса издателя карты (по сути update баланса)
Положительный ответ на внешний входящий карточный запрос
Получение подтверждения что ответ получен внешним источником операции (по сути update операции)
Каждый "шаг" по пути обработки по сути "добавляет" новую информацию к первоначальному карточному запросу. И так можно сделать в нужном количестве потоков получения карточных операций (поскольку поступают они на множество сетевых портов). И последовательностью и целостностью действий/информации в этом случае "рулит" БД (это гарантирующая составляющая обработки данных). "Падает" один процесс - остальные работают, целостность информации всегда есть. Еще часто этот процесс "разбивают" на 2 "короткие" транзакции в БД (1-3 и 5-8) + очередь в БД на 4 шаге. Что-то более оптимального насколько мне известно не придумали....
Ваши "идеи" -
последовательность входящей очереди обработки организовывать самостоятельно (kafka или redis) (один процесс/поток не сможет)
Проверка баланса (из базы)?
Отправка запроса на одобрение издателю карт (видимо по порядку очереди поступления?) Каким образом фиксировать выполнение этой операции? Еще одна очередь?
Проверка таймаута ответа (10 секунд)
Получение авторизации/одобрения издателем (видимо еще одна отдельная очередь со своим порядком?)
Дебетование единого баланса издателя карты (видимо периодическое в БД, по сумме операций из очереди выше?)
Положительный ответ на внешний входящий карточный запрос. Еще одна очередь? Ее порядок?
Получение подтверждения что ответ получен внешним источником операции
Запись всей информации по операции в БД. Где взять "всю информацию"? Из всех очередей выше? Или "перекладывать" ее из очереди в очередь?
Что делать при проблемах/тормозах в любой из очередей? Дублировать + контролировать "вручную" (дополнительным процессом) и обрабатывать все возможные ситуации? Именно это вы называете оптимальной "архитектурой"?
Да уж... Сколько по времени лет Oracle "отлаживал" ASM Tuning? И только в последних версиях (начиная с 19) он стал работать более менее адекватно...
Какой "самонастраивающийся механизм" знает что завтра у вас будет обновление прикладного приложения с введением нового функционала и измененным "профилем нагрузки", или что "завтра" вы будете делать upgrade версии DB с "улучшенным функционалом"?
Может "самонастраивающийся механизм" (до запуска пользователем "тяжелой для БД" прикладной процедуры) распределить ресурсы/нагрузку между множеством пользователей/процессов в БД "по желанию" администратора ("сегодня так а завтра по другому"), поскольку общая нагрузка не постоянна "по времени"?
Может "самонастраивающаяся БД" знать, что завтра у вас количество пользователей или клиентов прикладного приложения увеличиться на 30% (поскольку с завтрашнего дня у вас новый клиент или договоры)?
Просто "посмотрите" на "самонастраивающиеся" виртуальные сервера, у которых "регуляторов" по сути менее 20 (причем всего 4 типов CPU, RAM, IO диск и сеть), и сравните с современными БД (регуляторы которых "в прямую" зависят от ресурсов OS)...
Ну как бы конкретную DB в любом случае нужно подстраивать/оптимизировать под специфику прикладного приложения (с учетом доступных ресурсов и профиля нагрузки на нее) и это задача DBA... Другой вопрос что прикладное приложение должно "учитывать особенности реализации конкретной DB", а это сейчас большая проблема для современных прикладных разработчиков которые "по факту" только сторонними фреймворками и умеют пользоваться...
:-) Если в прикладной обработке на Oracle использовались множественные SELECT + UPDATE (и это "прокатывало", причем это конечно "скрыто" внутри GetObject(a) + SetObjectProperty(b) ), то на PG получаем "проблемы производительности"....
Полностью согласен... Принципы реализации многих "базовых" функций БД в Oracle и PG различные. Если прикладной софт, прикладные разработчики это "не учитывают" - при миграции приложения получите "как минимум" значительное падение прикладной производительности. Особенно на OLTP прикладных системах...
:-) Если пользователь четко не определил что он "хочет" (хоть на определенном этапе работы, хоть на весь финальный "заказ") - объем "бесполезной" работы исполнителя будет абсолютно одинаковый....
"Скрам нужен, когда вы понимаете что хотите, но не понимаете как достичь. И тут с помощью инкремента вы ищите свой путь " - а "потом" "вдруг" выясняется что ваше "понимание" (и проделанная вами работа) скажем так - не совпадает с пониманием целей и "хотелок" заказчика... :-)
А вот это - правильный вопрос! :-) Ни одному государству в мире умные граждане не нужны. Они ведь могут думать и задавать "неудобные вопросы"...
:-) Я бы добавил так... У них в голове "объекты"... Ну понятно что для объекта проще всего сделать GetObject(i) -> SetObjectProperties(j) -> WriteObject(i)....
А то что "за этим" стоит в БД им как бы "фиолетово"... И "получается" что вместо "update table set prop=x where id=i" в БД "получаем" select * from table where id=i (и это еще хорошо что в одной таблице, а могут выбирать все "свойства объекта" и из 10 по разным связкам + штук 5 "справочников") + зачастую могут выбирать и с блокировкой строк эксклюзивной и "подождать" реакции пользователя или удаленного сервиса с минуту + update (и хорошо если в одной таблице), а то могут обновить данные в нескольких связанных (ну вот такая у них "модель данных хранения")....
И все это у них называется "объектное программирование".... :-)
:-) Забудем на минуту "тонкие и сложные нанометры" и вспомним "добрым словом" "отечественный" легковой автопром... Как там соотношение между "хорошо и дорого"? :-) А вроде и технологии все не заоблачно сложные....
Про "выглядит" ничего не могу сказать... Могу прокомментировать только про "звучит"...
Железо соответствует минимально необходимому на текущий момент для подобных устройств (процессор и оперативка). Разнообразные китайские аналоги в рознице с подобными характеристиками CPU и флеш (но 4GB RAM что предпочтительней, т.к. работа приставки будет более "живой") дешевле на 1000 рублей (20%)... Так чем же хочет привлечь покупателей поставщик такого устройства? Жесткой привязкой к своей "экосистеме"? :-)
Почему так дорого то? :-)
Брал - UIG NF7840HS Ноутбук 16", AMD Ryzen 7 7840HS, RAM 16 ГБ, SSD 1024 ГБ, AMD Radeon 780M, Windows Pro, (7840), серый, Русская раскладка - менее 470$ на озон..... А это ноут с нормальным экраном...
Это полная чушь... Невозможно отключить то что не имеет доступа в сеть... Ну а если вы его предоставили - значит не читали описание и условия взлома лицензии.
:-) У каждого свой реальный опыт и кругозор... Отказ "сайта банка" несет "немного" другие последствия, чем отказ центрального процессинга целой страны или платежной системы банка с 50 млн. активных клиентов и гигантской эквайринговой сети...
"Появлись много noSQL решений, которые в обмен на рпотерю "крутой" транзакционности дали скорострельность, гибкость и все такое." - именно "все такое" но не ACID....
Тут "главный критерий", а кто будет "расплачиваться" при "потере" нескольких млн. $ + репутации, когда "замечательные" решения "потеряют" финансовые транзакции? :-) Опять видны "уши" agile - "будем решать проблемы по мере их поступления"
У людей постоянно занимающихся тестами на производительность и устойчивость высокопроизводительных технологических OLTP решений (включая кластеризацию, виртуализацию, контейнеризацию, шардирование баз на разных уровнях) - "есть другое мнение", чем у "теоретиков" начитавшихся маркетинговой чуши.
"Я думаю, очевидно, что крутится в контейнере, а что - нет." - я тоже... :-)
И не очень понял как контейнеры относятся к нашему предмету обсуждения - "работы OLTP БД"....
Что касается "нарезать" сразу - то пару раз в году (на праздники) нагрузка на БД и приложение раза в 3 выше чем остальные 360 дней. Будете "резать" с этим учетом? А под StandBy и DRS еще "нарезать" (с учетом что StandBy без нагрузки раза в 2-3 требует меньше ресурсов)? Очень экономно... А под пару периодических нагрузочных тестовых систем (плюс с десяток под функциональные тесты) - еще ресурсов "заранее нарезать"? Я уж про межкластерные сетевые требования и задержки (при отсутствии специализированных шин обмена) и не говорю... :-)
Да-уж... DML транзакции БД выполняются всегда "последовательно" (см. SCN).
:-) "Набирайте" сколько хотите пока не случится такое - https://habr.com/ru/news/800851/
У вас в контейнере БД работает? :-)
"Я не настолько богатый, чтобы покупать дешевые решения..." :-)
1) "Проверка 3DS может является частью этого шага" - не является... 3DS проверка это опциональный шаг выполняемый до авторизации.
2) "между которыми 10 может быть до 10 секунд" - именно может, а не всегда проходит (по факту "в среднем" 1,5 секунды отдельные пики до 2, 2-10 только штучные на периоде в сутки).
3) "иногда не только" - всегда поскольку это принцип работы OS с памятью на любых платформах.
4) На LPAR вы динамически (и даже автоматически на уровне виртуализации) можете "распределить" все ресурсы (и CPU и память и IO). На других платформах "в ручную" так же (HP,Oracle). Но только IBM это делает без "фриза" всей OS (и ее процессов) под нагрузкой на момент изменения количества CPU и RAM. Тесты были на всем (включая Exadata, HP UX и т.п. решениях). Если есть у вас возможность проверить - можете убедиться. :-)
Что касаемо Exadata то для прикладных OLTP систем она "особо" не лучше любых навороченных Enterprise систем. Единственное ее неоспоримое преимущество - один вендор при использовании Oracle DB.
Еще раз... 3DS проверка - отдельная процедура и не имеет отношения к обработке карточной операции. Точнее имеет (поскольку использует параметры карточной) но выполняется "независимо" и завершается до процесса авторизации (а вот он уже использует ее данные).
Если в транзакции вы используете select for update то - блокировка длится до commit/rollback. Причем тут 10 секунд? 10 секунд это допустимый максимум ответа, а не постоянная величина....
Лочится не "строка" - а "блок данных" (там и N строк м.б.) причем в памяти...
Впрочем от IBM и ее технологий мы уже "ушли далеко". Но... Только на IBM P тот же Oracle без "пауз в работе БД" ("провалов" TPS) позволял менять количество доступных OS виртуальных ядер (ни одна платформа этого не позволяет) и только IBM динамически может перераспределять общие/единые ресурсы между виртуальными машинами.
3DS - это не про финансы... Это тупо проверка что "клиент реально твой" и идет "на стороне издателя". Ее результат тупо "пристегивается" к запросу операции.
:-) Если все "в одной транзакции" - БД рулит корректным состоянием данных. На 2 шаге проверяется что текущий баланс минус сумма самой операции более 0. И поскольку последовательный "порядок" операций контролируется БД (а "по другому" ни одна ACID БД не работает), то все будет OK нужная сумма "будет всегда" и "отрицательный" ответ авторизации не изменит баланс. Учите теорию баз. "Проблемы" возникают только с блокировками в данном случае.
А вот вариант "уменьшить" блокировки путем "деления" на две транзакции - и приводит к описанным вами "проблемам" - через 10 секунд "порядок" исполнения меняется (баланс м.б. не таким как при первой транзакции проверки баланса). И вот тут реально и начинается "отдельная песня". С дополнительными "искусственными" транзакциями/операциями отмены/корректировки и т.п.
Читайте свои "тонны книг", но согласно математике 2+2 равно 4, а не "5 если продаем и 3 если покупаем" - как вы предлагаете. :-) Любые "авторизации" + "подтверждения" еще более нагружают и усложняют систему. Любые взаимодействия с "внешними" сервисами/"прокладками" увеличивают время "блокировки" или меняют "исходный" порядок операций.
И мы пока еще даже "не касались" "проблем устойчивости и надежности" всей системы "в целом"... :-)
Вы просто реально "не в теме", мое описание процесса содержит хорошо если 10% бизнес условий (скажем так "самое узкое место").
Очень сильно напоминает ajile подход - " Видим путь в тумане только на 5 метров в одном направлении, но все равно бежим туда, может и добежим в конечную точку, а может нет..."
Вы же как "архитектор" не разбираясь до конца в сути уже начинаете предлагать конкретные решения. :-)
Почему именно kafka, почему именно redis? "Стильно, модно, молодежно?" Как то блокчейна не хватает и IA... :-)
Что значит "строго последовательно" 10 операций поступили извне в одну и ту же милисекунду, где тут последовательность? "Последовательность транзакций/операций" может только на уровне БД или единой очереди "возникнуть"....
И еще раз - последовательность поступления карточных операций по времени <> последовательности взаимодействия этих операций с балансом единого счета + между временем поступления карточной операции и временем ее взаимодействия с балансом единого счета может пройти до 10 секунд.
Опять же очень сильно упрощенно, по основным шагам и при положительных проверках, в одной БД транзакции получаем -
Внешний входящий запрос на карточную операцию в БД (по сути insert операции).
Проверка единого баланса издателя на допустимость операции к исполнению (по сути select баланса)
Отправка запроса на одобрение издателю карт (по сути update операции)
Проверка таймаута ответа (10 секунд)
Получение авторизации/одобрения издателем (по сути update операции)
Дебетование единого баланса издателя карты (по сути update баланса)
Положительный ответ на внешний входящий карточный запрос
Получение подтверждения что ответ получен внешним источником операции (по сути update операции)
Каждый "шаг" по пути обработки по сути "добавляет" новую информацию к первоначальному карточному запросу. И так можно сделать в нужном количестве потоков получения карточных операций (поскольку поступают они на множество сетевых портов). И последовательностью и целостностью действий/информации в этом случае "рулит" БД (это гарантирующая составляющая обработки данных). "Падает" один процесс - остальные работают, целостность информации всегда есть. Еще часто этот процесс "разбивают" на 2 "короткие" транзакции в БД (1-3 и 5-8) + очередь в БД на 4 шаге. Что-то более оптимального насколько мне известно не придумали....
Ваши "идеи" -
последовательность входящей очереди обработки организовывать самостоятельно (kafka или redis) (один процесс/поток не сможет)
Проверка баланса (из базы)?
Отправка запроса на одобрение издателю карт (видимо по порядку очереди поступления?) Каким образом фиксировать выполнение этой операции? Еще одна очередь?
Проверка таймаута ответа (10 секунд)
Получение авторизации/одобрения издателем (видимо еще одна отдельная очередь со своим порядком?)
Дебетование единого баланса издателя карты (видимо периодическое в БД, по сумме операций из очереди выше?)
Положительный ответ на внешний входящий карточный запрос. Еще одна очередь? Ее порядок?
Получение подтверждения что ответ получен внешним источником операции
Запись всей информации по операции в БД. Где взять "всю информацию"? Из всех очередей выше? Или "перекладывать" ее из очереди в очередь?
Что делать при проблемах/тормозах в любой из очередей? Дублировать + контролировать "вручную" (дополнительным процессом) и обрабатывать все возможные ситуации? Именно это вы называете оптимальной "архитектурой"?