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 секунд)
Получение авторизации/одобрения издателем (видимо еще одна отдельная очередь со своим порядком?)
Дебетование единого баланса издателя карты (видимо периодическое в БД, по сумме операций из очереди выше?)
Положительный ответ на внешний входящий карточный запрос. Еще одна очередь? Ее порядок?
Получение подтверждения что ответ получен внешним источником операции
Запись всей информации по операции в БД. Где взять "всю информацию"? Из всех очередей выше? Или "перекладывать" ее из очереди в очередь?
Что делать при проблемах/тормозах в любой из очередей? Дублировать + контролировать "вручную" (дополнительным процессом) и обрабатывать все возможные ситуации? Именно это вы называете оптимальной "архитектурой"?
Вопрос же простой, есть четкая постановка задачи, и она не параллелится. Ваши "архитектурные предложения" не решают поставленную задачу, и вместо этого вы предлагаете "разнообразные костыли". Да рабочие, но не решающие поставленную задачу. И проблема тут не в БД как таковой, а в архитектурых особенностях работы CPU (особенно многоядерных) с памятью как таковой. Кроме частоты CPU и памяти на уровне OS есть параметры влияющие как на время блокировки "захваченной на модификацию" области памяти одним процессом, так и на время через которое другой процесс OS пытается (после не успешного "захвата") "захватить на модификацию" эту же область памяти. На уровне приложения OS ПО (в частности различные БД) так же по разному реализуют работу в многопоточности и так же часто имеют "собственные" механизмы блокировки доступа.... То что "кешей много и разных" только усложняет (и даже замедляет) процедуры работы CPU с одной областью памяти (типа область в кеше на одном ядре, а модифицирует другое ядро и т.п.).
:-) "тачка на квадратных колесах" - это текущие и предлагаемые вами решения... Собственно мой комент возник на ваше утверждение - "База куда эффективнее "разгоняется" стороними технологиями вроде кеша или noSQL или column-based. Если нет потребности "держаться" за реляционную алгебру, мир сразу становится шире"... Проблема производительности текущих OLTP баз чаще всего не в скорости/объеме дисков и не в количестве CPU/ядер, а в эффективности CPU и скорости работы с памятью (поскольку блокировки на уровне блока), а в блоке памяти лежит достаточно много модифицируемых данных....
:-) В вашем понимании "последовательно" это как? В "понимании" банка издателя в последовательности его ответов одобрения на транзакционные запросы (и "по факту" это верно). Не важно что на 5000 транзакций посланных ему 5 секунд назад он не прислал ответа, важно что он уже ответил на 5000 транзакций отправленных ему секунду назад. И именно эта сумма может быть списана с его депозита и именно эти клиенты получат деньги в банкомате или оплатят заказ (сделают перевод) в интернет магазине банка эквайера. Вам логика понятна? Не проблема сделать 20 000 операций в БД, проблема сделать их в соотвествии с заданной клиентом бизнес логикой. Конечно проще всего "подогнать" бизнес логику под "существующую технологию" и отвечать клиенту - "вот где карту получали - в то отделение и идите....". Аналогия вам надеюсь понятна? А насчет "надежности" в памяти.... Чудес не бывает... Падают любые процессы и OS... Что же касается "выбить через суд" и т.п. - если бы было "все просто и легко" никто бы и не стал "заморачиваться" с ACID и Online обработкой финансов в принципе (как впрочем и было лет 40 назад)... Чеки и кредитные карты в оффлайн тогда "рулили"...
:-) А чем принципиально "страховой депозит" издателя в VISA отличается от "страхового депозита" издателя в банке эквайере (или страхового депозита банка в платежной системе). И еще раз повторю, что не от "хорошей жизни" расчет комиссии и проверку баланса на "страховом депозите" делают не в Online (а в Offline или псевдо Online)... А потому что нет транзакционной технологии (включая БД и прочую технологическую обвязку) позволяющую делать это "без костылей"....
:-) Для того чтобы понимать нужно быть "в теме".... Не смущает же никого сейчас что банки "морозят" депозиты на расчетных счетах в VISA и MC. :-) Те же VISA и MC имеют несколько "региональных" центров, замыкающих на себя межбанковский трафик региона и обменивающихся только "межрегиональным" трафиком (с учетом того что внутрибанковский Online трафик туда и не попадает). И у той же VISA в ее центрах стоит по десятку IBM P Series серверов (по крайней мере так было еще лет 10 назад). Использование Single Message протоколов обмена (авторизация=финансовой операции), вместо Dual Message (где финансовые могут "приходить" и вообще без авторизации) все более актуально при дальнейшем развитии постоянной Online связи. В середине 2000-х сбер начал (с большой "помпой") внедрять IBM P System (топовые на тот момент P795) в свои региональные центры (с разделением на front и back системы) и Греф "топил" за них, в середине 2010-х новые "эффективные менеджеры" (с новыми откатами) начали очередной виток "развития"...
1. Правила настраивает не эмитент, а эквайер (который не готов терять средства), а это означает что банк эмитент "не получит" операции минимум за период максимального таймаута выделенного для авторизации собственного клиента именно банку эмитенту (обычно не более 10 сек). А 10 сек - это 50 000 операций.... Так что будут "страдать" именно клиенты чужого банка. 2. Операции по корсчету банка издателя банк эквайер может делать только после того как банк издатель их (на своей стороне) авторизует/одобрит по своим клиентам. Иначе "появляются вопросы" типа - "я отказал клиенту, а по корсчету операция прошла".... 3. Про варианты выбора я согласен с вами, но часто требования бизнеса могут быть довольно жесткие, и выбирают из многих вендоров того кто более им соответствует.... Но собственно вопрос то в "модных" решениях (очередной "серебряной пуле" которых уже много было) не решающих по факту "узких" мест OLTP производительности....
:-) Для информации... Китайский/индийский/<....> банк (даже не входящий в первую пятерку) делает внутри страны операций больше чем сбер у нас. Варианты "отложенная проверка" или "не точная проверка" или "прогнозируемая проверка" конечно остаются всегда и являются возможными (хотя и "костыльными") решениями (ровно так же как и не online расчет комиссий), но мы то говорим о организации "прямой и в лоб" проверке через запросы/statemen в БД. И "вот тут" никакие "новомодные решения" работы с БД не работают, от слова совсем.... То что банки/финансисты считают считают комиссии по Online операциями "не в online" это не их желание... :-) Я не думаю что вам понравится ситуация если вам "заблокируют" операции по карте в 1000 рублей если у вас еще доступно 10 000 (по причине "через минуту условно деньги все равно закончатся").... К примеру одна минута при 1000 TPS - 60 000 операций - значит 60 000 "не обоснованных в принципе" отказов в обслуживании....
Все просто, даже очень... :-) У банка есть эквайринговая сеть (ну к примеру 10000 банкоматов, 50000 POS теримналов + пара-тройка больших маркетплейсов торгующих через интернет + прием коммуналки на сайте и т.п.) принимающая карты (и в том числе "чужих банков" которых скажем два-три и с которыми у вас есть договор на прямые взаиморасчеты). Поскольку терминалы и торговцы ваши (вам с ними и рассчитываться в любом случае т.к. они "услугу или товар предоставили"), а вот вероятность что "чужой банк" вам возмещение (по операциям своих клиентов) не предоставит (денег не переведет) - всегда есть. В таком случае "чужому банку" вы "говорите" - я (как банк эквайер) готов обслуживать ваших клиентов по их картам, но для исключения моих рисков (что вы со мной не рассчитаетесь после того как я обслужу ваши карты) вы вносите на свой счет в моем банке "страховой депозит" в том размере какой сочтете сами необходимым. Пока средства на вашем счете есть - я обслуживаю ваши карты. Вот и все. Вы обслуживаете карты "чужих" клиентов по этому правилу. И каждая операция с чужой картой проверяет наличие суммы этой операции на счете чужого банка и если сумма на счете позволяет, уменьшает сумму на этом счете на свою величину.... :-) Операций по чужим картам много, но все они "проходят" через один "страховой счет".
И еще "одна мелочь".... Кроме собственно суммы операции по одной "чужой карте" через тот же счет может проходит "сумма комиссии" которую вы м.б. возьмете по данной операции с "чужого банка".... Т.е. на одну операцию по чужой карте может проходить более одной операции через "страховой счет" чужого банка.... :-)
Да пишите вы куда угодно... :-) Чудес же не бывает... :-) Если область памяти читается и модифицируется множеством потоков/процессов одновременно (что и происходит в данном случае) вы будете иметь проблемы с блокировками в любом случае.... Не спасет вас новомодные микросервисы, шардинг и т.п. (только хуже будет), и только скорость CPU и памяти даст вам прирост.... Если у вас 5000 финансовых транзакций в секунду которым требуется проверить, что одна определенная сумма баланса не менее "чего-то" и каждая финансовая операция воздействует на этот "единый баланс"....
"База куда эффективнее "разгоняется" стороними технологиями вроде кеша или noSQL или column-based." :-) Попробуйте "разогнать" OLTP базу у которой 5000 insert в секунду в одну таблицу (или несколько) все проверяют (до своего исполнения) одно уникальное значение поля в другой таблице и после успешной проверки это же уникальное значение модифицируют.... :-)
А "поверх" этой асинхронности взаимодействия с сетью накладываются ограничения... :-) Если за N ms из сокета поступило менее X байт - закрой сокет и сделай X, если за M ms из сокета не поступило "полное" сообщение - закрой сокет и сделай Y, а вот если за N ms из сокета "ничего" не поступило - закрой сокет и сделай Z.... :-)
А зачем вам otp? Вам же нужен конкретный сервис? Делать зависимость сервиса от другого сервиса (а собственно все вторые факторы именно так и делают) - плохая идея... Есть сервис - есть его клиент - есть аутентификация клиента в конкретном сервисе. Остальное то зачем? Куда более интуитивно чем "только клиент знает как аутентифицироваться"? И только сервис знает "как аутентифицировать" своего клиента? Остальное - только менее безопасно и сложнее для клиента. Просто в отличии от обычного пароля, динамический значительно усложняет "перехват" и "подсматривание"... Но в отличии от биометрии пароль позволяет при желании (или компрометации) "сменить" аутентификационные данные без проблем.
Задача сервиса - предоставить его пользователю вне "зависимости" от устройства "потребления". Об это почему то "забывают" те кто ратует "за владение" как второй фактор аутентификации пользователя....
Единственная "проблема" паролей - возможность их "перехвата" на устройстве ввода (не касаясь проблемы что их нужно помнить в голове). Динамический пароль - случайная часть основного пароля, что позволяет не получить (даже в случае "перехвата") весь пользовательский пароль. Может быть как дополнительный к "основному" паролю аутентификации.
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 секунд)
Получение авторизации/одобрения издателем (видимо еще одна отдельная очередь со своим порядком?)
Дебетование единого баланса издателя карты (видимо периодическое в БД, по сумме операций из очереди выше?)
Положительный ответ на внешний входящий карточный запрос. Еще одна очередь? Ее порядок?
Получение подтверждения что ответ получен внешним источником операции
Запись всей информации по операции в БД. Где взять "всю информацию"? Из всех очередей выше? Или "перекладывать" ее из очереди в очередь?
Что делать при проблемах/тормозах в любой из очередей? Дублировать + контролировать "вручную" (дополнительным процессом) и обрабатывать все возможные ситуации? Именно это вы называете оптимальной "архитектурой"?
Вопрос же простой, есть четкая постановка задачи, и она не параллелится. Ваши "архитектурные предложения" не решают поставленную задачу, и вместо этого вы предлагаете "разнообразные костыли". Да рабочие, но не решающие поставленную задачу. И проблема тут не в БД как таковой, а в архитектурых особенностях работы CPU (особенно многоядерных) с памятью как таковой. Кроме частоты CPU и памяти на уровне OS есть параметры влияющие как на время блокировки "захваченной на модификацию" области памяти одним процессом, так и на время через которое другой процесс OS пытается (после не успешного "захвата") "захватить на модификацию" эту же область памяти. На уровне приложения OS ПО (в частности различные БД) так же по разному реализуют работу в многопоточности и так же часто имеют "собственные" механизмы блокировки доступа....
То что "кешей много и разных" только усложняет (и даже замедляет) процедуры работы CPU с одной областью памяти (типа область в кеше на одном ядре, а модифицирует другое ядро и т.п.).
:-) "тачка на квадратных колесах" - это текущие и предлагаемые вами решения...
Собственно мой комент возник на ваше утверждение - "База куда эффективнее "разгоняется" стороними технологиями вроде кеша или noSQL или column-based. Если нет потребности "держаться" за реляционную алгебру, мир сразу становится шире"...
Проблема производительности текущих OLTP баз чаще всего не в скорости/объеме дисков и не в количестве CPU/ядер, а в эффективности CPU и скорости работы с памятью (поскольку блокировки на уровне блока), а в блоке памяти лежит достаточно много модифицируемых данных....
:-) В вашем понимании "последовательно" это как? В "понимании" банка издателя в последовательности его ответов одобрения на транзакционные запросы (и "по факту" это верно). Не важно что на 5000 транзакций посланных ему 5 секунд назад он не прислал ответа, важно что он уже ответил на 5000 транзакций отправленных ему секунду назад. И именно эта сумма может быть списана с его депозита и именно эти клиенты получат деньги в банкомате или оплатят заказ (сделают перевод) в интернет магазине банка эквайера. Вам логика понятна?
Не проблема сделать 20 000 операций в БД, проблема сделать их в соотвествии с заданной клиентом бизнес логикой. Конечно проще всего "подогнать" бизнес логику под "существующую технологию" и отвечать клиенту - "вот где карту получали - в то отделение и идите....". Аналогия вам надеюсь понятна?
А насчет "надежности" в памяти.... Чудес не бывает... Падают любые процессы и OS...
Что же касается "выбить через суд" и т.п. - если бы было "все просто и легко" никто бы и не стал "заморачиваться" с ACID и Online обработкой финансов в принципе (как впрочем и было лет 40 назад)... Чеки и кредитные карты в оффлайн тогда "рулили"...
:-) А чем принципиально "страховой депозит" издателя в VISA отличается от "страхового депозита" издателя в банке эквайере (или страхового депозита банка в платежной системе). И еще раз повторю, что не от "хорошей жизни" расчет комиссии и проверку баланса на "страховом депозите" делают не в Online (а в Offline или псевдо Online)... А потому что нет транзакционной технологии (включая БД и прочую технологическую обвязку) позволяющую делать это "без костылей"....
:-) Для того чтобы понимать нужно быть "в теме"....
Не смущает же никого сейчас что банки "морозят" депозиты на расчетных счетах в VISA и MC. :-)
Те же VISA и MC имеют несколько "региональных" центров, замыкающих на себя межбанковский трафик региона и обменивающихся только "межрегиональным" трафиком (с учетом того что внутрибанковский Online трафик туда и не попадает). И у той же VISA в ее центрах стоит по десятку IBM P Series серверов (по крайней мере так было еще лет 10 назад).
Использование Single Message протоколов обмена (авторизация=финансовой операции), вместо Dual Message (где финансовые могут "приходить" и вообще без авторизации) все более актуально при дальнейшем развитии постоянной Online связи.
В середине 2000-х сбер начал (с большой "помпой") внедрять IBM P System (топовые на тот момент P795) в свои региональные центры (с разделением на front и back системы) и Греф "топил" за них, в середине 2010-х новые "эффективные менеджеры" (с новыми откатами) начали очередной виток "развития"...
1. Правила настраивает не эмитент, а эквайер (который не готов терять средства), а это означает что банк эмитент "не получит" операции минимум за период максимального таймаута выделенного для авторизации собственного клиента именно банку эмитенту (обычно не более 10 сек). А 10 сек - это 50 000 операций.... Так что будут "страдать" именно клиенты чужого банка.
2. Операции по корсчету банка издателя банк эквайер может делать только после того как банк издатель их (на своей стороне) авторизует/одобрит по своим клиентам. Иначе "появляются вопросы" типа - "я отказал клиенту, а по корсчету операция прошла"....
3. Про варианты выбора я согласен с вами, но часто требования бизнеса могут быть довольно жесткие, и выбирают из многих вендоров того кто более им соответствует....
Но собственно вопрос то в "модных" решениях (очередной "серебряной пуле" которых уже много было) не решающих по факту "узких" мест OLTP производительности....
:-) Для информации... Китайский/индийский/<....> банк (даже не входящий в первую пятерку) делает внутри страны операций больше чем сбер у нас.
Варианты "отложенная проверка" или "не точная проверка" или "прогнозируемая проверка" конечно остаются всегда и являются возможными (хотя и "костыльными") решениями (ровно так же как и не online расчет комиссий), но мы то говорим о организации "прямой и в лоб" проверке через запросы/statemen в БД. И "вот тут" никакие "новомодные решения" работы с БД не работают, от слова совсем....
То что банки/финансисты считают считают комиссии по Online операциями "не в online" это не их желание... :-)
Я не думаю что вам понравится ситуация если вам "заблокируют" операции по карте в 1000 рублей если у вас еще доступно 10 000 (по причине "через минуту условно деньги все равно закончатся")....
К примеру одна минута при 1000 TPS - 60 000 операций - значит 60 000 "не обоснованных в принципе" отказов в обслуживании....
Все просто, даже очень... :-)
У банка есть эквайринговая сеть (ну к примеру 10000 банкоматов, 50000 POS теримналов + пара-тройка больших маркетплейсов торгующих через интернет + прием коммуналки на сайте и т.п.) принимающая карты (и в том числе "чужих банков" которых скажем два-три и с которыми у вас есть договор на прямые взаиморасчеты). Поскольку терминалы и торговцы ваши (вам с ними и рассчитываться в любом случае т.к. они "услугу или товар предоставили"), а вот вероятность что "чужой банк" вам возмещение (по операциям своих клиентов) не предоставит (денег не переведет) - всегда есть. В таком случае "чужому банку" вы "говорите" - я (как банк эквайер) готов обслуживать ваших клиентов по их картам, но для исключения моих рисков (что вы со мной не рассчитаетесь после того как я обслужу ваши карты) вы вносите на свой счет в моем банке "страховой депозит" в том размере какой сочтете сами необходимым. Пока средства на вашем счете есть - я обслуживаю ваши карты.
Вот и все. Вы обслуживаете карты "чужих" клиентов по этому правилу. И каждая операция с чужой картой проверяет наличие суммы этой операции на счете чужого банка и если сумма на счете позволяет, уменьшает сумму на этом счете на свою величину.... :-)
Операций по чужим картам много, но все они "проходят" через один "страховой счет".
И еще "одна мелочь".... Кроме собственно суммы операции по одной "чужой карте" через тот же счет может проходит "сумма комиссии" которую вы м.б. возьмете по данной операции с "чужого банка".... Т.е. на одну операцию по чужой карте может проходить более одной операции через "страховой счет" чужого банка.... :-)
Да пишите вы куда угодно... :-) Чудес же не бывает... :-)
Если область памяти читается и модифицируется множеством потоков/процессов одновременно (что и происходит в данном случае) вы будете иметь проблемы с блокировками в любом случае....
Не спасет вас новомодные микросервисы, шардинг и т.п. (только хуже будет), и только скорость CPU и памяти даст вам прирост....
Если у вас 5000 финансовых транзакций в секунду которым требуется проверить, что одна определенная сумма баланса не менее "чего-то" и каждая финансовая операция воздействует на этот "единый баланс"....
"База куда эффективнее "разгоняется" стороними технологиями вроде кеша или noSQL или column-based." :-)
Попробуйте "разогнать" OLTP базу у которой 5000 insert в секунду в одну таблицу (или несколько) все проверяют (до своего исполнения) одно уникальное значение поля в другой таблице и после успешной проверки это же уникальное значение модифицируют.... :-)
На тестах производительности pSeries выигрывает у zSeries...
Да и перспективой Oracle DB на них большие проблемы...
А "поверх" этой асинхронности взаимодействия с сетью накладываются ограничения... :-)
Если за N ms из сокета поступило менее X байт - закрой сокет и сделай X, если за M ms из сокета не поступило "полное" сообщение - закрой сокет и сделай Y, а вот если за N ms из сокета "ничего" не поступило - закрой сокет и сделай Z.... :-)
А зачем вам otp? Вам же нужен конкретный сервис?
Делать зависимость сервиса от другого сервиса (а собственно все вторые факторы именно так и делают) - плохая идея...
Есть сервис - есть его клиент - есть аутентификация клиента в конкретном сервисе. Остальное то зачем? Куда более интуитивно чем "только клиент знает как аутентифицироваться"? И только сервис знает "как аутентифицировать" своего клиента? Остальное - только менее безопасно и сложнее для клиента.
Просто в отличии от обычного пароля, динамический значительно усложняет "перехват" и "подсматривание"... Но в отличии от биометрии пароль позволяет при желании (или компрометации) "сменить" аутентификационные данные без проблем.
99,99% - это 52 минуты простоя в год.... :-)
Задача сервиса - предоставить его пользователю вне "зависимости" от устройства "потребления". Об это почему то "забывают" те кто ратует "за владение" как второй фактор аутентификации пользователя....
Единственная "проблема" паролей - возможность их "перехвата" на устройстве ввода (не касаясь проблемы что их нужно помнить в голове). Динамический пароль - случайная часть основного пароля, что позволяет не получить (даже в случае "перехвата") весь пользовательский пароль. Может быть как дополнительный к "основному" паролю аутентификации.
Чем больше доступных клиенту способов - тем лучше. Но вот динамического пароля у вас нет...
"технический овердрафт" - вынужденная ситуация, и избегать ее техническими средствами необходимо в различных случаях....