Так там дело обычно не в iops.

В потоках, блокировках, старой архитектуре и т.п.

Так мы-то о чем говорим? Транзакции для изменения нескольких счетов - это как раз выливается в блокировки. И даже без них, ты все равно не присадишь крупный трафик на 1 шард.

Таймпад козел. Кому не пришло письмо-подтверждение на оффлайн митап с адресом и временем встречи - напишите в личку, пожалуйста.

Так длинные блокировки и процесс на активную транзакцию - не обязательны. А так 20k tps на одном узле вполне достижимы, а какой крупный мерчант имеет больше? Амазон, Али, Таобао?

И какая из альтернатив не имеет аналога двойной записи? А конкретно про 20k tps на узел даже с оптимистичными блокировками и другими подобными ухищрениями - сомневаюсь. rps - легко, а вот tps - не верю.

Так если мы про перевод денег, то там tps и rps - примерно про одно. Это же не весь длинный платеж (где аккаунтинг - самая простая операция)

Хотя да, нам в любом случае нужен индекс изменений по счету, а это фактически двойная запись.
Да, ты прав.

Я бы не сказал, что в OLTP rps и tps одно. Нужно же не просто регистрировать авторизации, но и изредка делать рефанды и отмены, а для этого надо гарантировать, что у пользователя отобрали "плюшки", которые он "купил".

Ну, авторизации до двойной записи не доходят, это еще процесс платежа, а не результат. Рефанд - еще одна операция.
Т.е. на аккаунтинге (и только на нем) у нас есть два update, один insert и два индекса обновляем.
Остальное - в процессе платежа. Ну, можно два insert, разница не принципиальна )

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

Во многих учётных системах по факту успешной авторизации уже начинает оказываться услуга, не дожидаясь расчётов.
Т.е. успешная авторизация влечёт за собой учёт "плюшек" пользователей - вот тебе уже два счёта. Если второй "счёт" не добавлять - то практически невозможно реализовать безопасные рефанды (такие, что бы у пользователя не было возможности "обмануть систему").

По поводу подсчёта операций, пожалуй соглашусь. Но обычно учитывают ещё и этапы авторизации, которые можно фиксировать в другом месте, - с ними гораздо печальнее. Ну и ещё фиксация собственно операции не конечный шаг - дальше понадобятся разные экспорты и т.д., для чего нужны будут отдельные индексы. Так что всё равно 20k tps нереально, КМК...

Не совсем понял. Прилетела авторизация, сделали холд, начали предоставлять услугу, в учётной системе вообще чисто. Клиент не прислал подтверждение - и что тогда?

В соответствие с бизнес правилами. Зависит от конкретной системы.

Я вообще про то, что процесс платежа и учет проводок на счетах - независимые действия. Платеж - это куча шагов, но они могут вообще в отдельной БД жить и никак с учётом не связаны. А в учетную систему попадают уже проводки после фиксации.

И пока не пришла фиксация после авторизации - нет ничего для учетной системы

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

Тоже зависит от системы. Обычно такие системы учета дополняют бухгалтерские системы. Но счета и проводки реализуют.

Ну да, я тоже так делал, есть процессинг со счетами, есть АБС. Но в процессинге мне не нужна двойная запись. На самом деле кластеризовать вообще нужно только процесс платежа, остальное дожмется или откатиться, можно вообще батчами делать.

А процесс платежа тривиально кластеризуется, платежи не имеют общего контекста, только счета.