Здравствуйте, Sinclair, Вы писали:

S>·>Т.е. вместо того, чтобы мучиться рассуждениями как должен себя вести сервер при получении дубликатов — просто можно считать, что до сервера дубликаты не доходят, а этим занимается прокси. Иными словами, вместо одного сверхумного компонента, рассматриваем два простых — тупой сервер который умеет обрабатывать один запрос без повторов и кеш который тупо возвращает то что видел.
S>Можно, но это никак не поможет рассуждать о корректности. В описанном сценарии прокси между A/B/C и сервисах ничего не изменят — по-прежнему состояние сервера будет разрушено, хотя каждый из клиентов всё делал безупречно.
Не очень ясно причём тут идемпотентность тогда. Идемпотентность никак не помогает рассуждать о корректности взаимодействия между множеством систем, только между двумя. Именно между двумя системами происходит State Transfer.

S>·>По-моему ты ожидаешь от идемпотентности больше, чем положено. Идемпотентность про одну операцию, а не про их взаимодействие. (вспомни формулу f ∘ f = f — там нет никаких A,Y,Z, ровно одна функция).
S>Я иду с другой стороны. У меня нет задачи "о, прикольная штука эта ваша идемпотентность, к чему бы полезному её пристроить". У меня задача — ровно наоборот: спроектировать и реализовать API, который позволяет написать к нему клиентов, которые смогут корректно работать при наличии сбоев.
Так это уже CAP.

S>·>А это всё разруливается бизнес-логикой и универсального решения нет.
S>Если мы придумаем решение для этой конкретной бизнес-логики, то оно легко станет универсальным.
S>·>Ну и CAP подлянки подстраивает.
S>Нет, CAP тут ни при чём.
Именно причём. У тебя происходит Partitioning (между клиентом и сервером произошел разрыв связи) и бизнес должен решить, чем жертвовать C или A.

S>·>Например, типично делают временную блокировку билета (скажем на 15 минут) в течение которой должна пройти успешно оплата. После этого уже резервирование билета.
S>Это вообще не решение. Вот у нас оплата успешно прошла, но клиент об этом не узнал. Дальше что?
Оплата прошла, билет куплен успешно. Если у клиент об этом не узнал (мобильник выпал из рук и разбился), то это забота клиента найти способ связаться и узнать о результате.

S>·>Притом, в случае технической проблемы (всё упало, и после оплаты не удалось уложиться в 15 минут завершить резервацию), то предусматривают ручную утряску или возврат денег.
S>Ну вот я и хочу избавиться от ручной утряски — это очень дорогостоящая процедура.
А есть варианты? И, главное, причём тут идемпотентность?