Стандарт решения проблемы двойных списаний в финтех, или О чем спросят системного аналитика на собеседовании

[SDWa]

Доходчиво изложено, спасибо. Насколько я понимаю, у варианта с блокировкой кнопки также недостаток в том что шибко умный юзер может дергать API через Postman и тем самым обходить блок кнопки на фронте.

[NIcie]

спасибо, рада! этот вариант тоже не назовешь случайным повтором )

[propell-ant]

В синхронном сценарии есть проблемка, между шагами 1 и 2 в браузерной реализации есть место для состояния гонки:

1. Пользователь нажимает кнопку Перевести
2. Кнопка становится неактивной
    Запрос уходит на сервер, интерфейс ждёт ответ

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

Описанный синхронный подход не защищает от этой гонки.

[andreygn]

Вниманимательно слушаю почему эта конструкция не будет работать? 👀

button.addEventListener('click', () => {

  button.disabled = true; // 1. Сначала выключаем

  sendData();             // 2. Потом отправляем

});

[propell-ant]

Между кликом и button.disabled = true проходит ненулевое время, в этот промежуток времени возникает состояние гонки.

[khristm]

Синхронный код, пока блокировка не выполнится, дальше не пойдёт, что тут непонятного

[nin-jin]

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

[PlatinumKiller]

Пытаюсь найти банк, но тут ни слова, хотя есть пару где есть такая беда

[kest70]

Вы прошли собес в итоге? Вам сделали оффер?

[NIcie]

в поиске, в переговорах, статьи пока пишу )

[blackyblack]

У вас алгоритм для идемпотентности некорректный. Если вы генерируете уникальный ключ на клиенте при нажатии кнопки, то повторные нажатия дадут разные уникальные ключи и пройдут две оплаты.

[NIcie]

ключ будем генерить до отправки запроса, и если параметры запроса не меняются, то и ключ не изменится

[blackyblack]

Ну ка, какие у вас будут параметры, которые формируют ключ? Сумма, отправитель и получатель? Тогда точно такая же отправка средств будет заблокирована, хотя по факту это именно другой перевод.

[Crabster]

Банально timestamp генерации формы даст уникальность

[blackyblack]

Да, но судя по схеме ТС ключ генерируется при нажатии кнопки, а не при формировании формы отправки.

[chegeras]

две вкладки, открытые в одно и то же время, приведут к тому, что два разных перевода будут восприняты как один

[nin-jin]

С такой удачей лучше купить партию лотерейных билетов.

[chegeras]

в асинхронном варианте вся проблема в том, кто решает новый это запрос или повторный.

если перезагрузили страницу и нажимаем перевод еще раз пока не получили ответ по первой операции, это будет новый запрос или повторный?

если надо выполнить подряд два одинаковых перевода(один и тот же получатель и сумма), то не получится ли что пользователю придет два подтверждения, а по факту перевод будет один?

[thevudi]

Ключом уникальности, обычно, выступает форма (страница) + timestamp (до нескольких минут).

Если ключ уникальности одинаковый, значит это один и тот же платеж. Если разные - это разные платежи.

[nin-jin]

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

[psychotv]

Имхо на frontend совсем не стоит полагаться. Имхо стоит рассматривать начало действия не в момент когда клиент "подтверждает перевод", а в момент когда он выбирает опцию - "сделать перевод". Именно в этот момент должен создаваться ключ операции (причем тоже не на стороне клиента) и именно с этим ключом операция и будет "финализироваться" ровно один раз, сколько бы запросов не отправлял клиент на сервер. Это и обеспечит идемпотентность.

[nin-jin]

А чтобы создать ключ операции нам нужно иметь ключ операции создания ключа операции…