Уважаемый Максим,
Моё приложение является многопользовательским, но решение с буфером (в данном частном случае) не создает описываемых проблем. В дополнение к тому, о чём написал Дмитрий Гончаренко,
За счет того, что соединение с сервером держится постоянно, каждая такая операция занимает секунды - т.е. не очень долго - и информацию о неудавшейся записи пользователь получает очень быстро, не успев выйти за контекст событий (обычно он все еще находится на той же странице). Это облегчает ему повторную отправку в случае случайной неудачи и одновременно предостерегает его от накопления большого количества действий в локальном буфере - психологически некомфортно добавлять записи если видишь, что они не попадают на сервер.
хочу добавить, что в моём приложении именно этот эффект и наблюдается: действительно, порции отправляемых из каждого "буфера" в конкретный момент времени изменений малы, отправка изменений занимает секунды, so даже, когда изменения на сервер отправляются одновременно от множества Пользователей, коллизий не возникает. Хотя коллизии вероятны, но, всё же, "одновременность" с точностью до доли секунды, событие очень редкое. Но даже, если бы такая накладка произошла (или произошло иное неучтённое событие), то соответствующее противоречие решается версионностью произошедших изменений.
Тем не менее, если абстрагироваться от этого приложения и попробовать ответить на общий вопрос о границах применения приёма, то, да, можно смоделировать ситуацию, когда соответствующие коллизии очень вероятны. Например, когда множество Пользователей работает с большим объемом одних и тех же данных и интервалы времени, требуемые для передачи соответствующих изменений велики (занимают не секунды, а минуты для отправки даже маленькой порции данных).
Предположим, десятка три (или больше, чтобы повысить вероятность обращения к одним и тем же данным) торговых точек резервируют товары из общего единого складского сервиса, но они не обращаются к серверу сразу, а работают, как описано здесь (через буфер с отправкой изменений с небольшим сдвигом по времени). Но почему-то время доставки этих изменений на сервер и записи их очень велико (я не знаю, почему, моделирую). Например, занимает не секунды, а минуты.
В таком модельном случае, при частом одновременном резервировании одних и тех же номенклатурных позиций разными многочисленными Пользователями, вполне вероятна ситуация, когда данные "на Клиентах" почти постоянно не будут совпадать с данными на сервере. И - соответственно - очень часто будут отправляться запросы, которые сервер будет отклонять - так, что, в предельном итоге, "никто ничего не допросится", хотя товар на складе есть. И версионность нам тут тоже не поможет, поскольку мы никак не можем иметь несколько версий фактического объема товара на складе.
Я бы сказал, что применимость приёма обратно пропорциональна числу определяемому произведением количества Пользователей (одновременно работающих с одними и теми же данными) на время обработки изменений этих данных. Всё же, в очень большом числе случаев это произведение невелико. Поэтому приём имеет довольно широкий сегмент применения.
Каждый приём имеет границы применимости, в корневой ветке же обсуждения содержался вопрос о том, как формализовывать опыт. Соответственно, один из шаблонов описания приведён. Приём описанный здесь (по данному шаблону) не единственный. У разработчика должна быть большая картотека приёмов и алгоритм их выбора (в идеале).
Спасибо за Ваши вопросы,
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ