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

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

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