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

S>Важно не наличие прокси, а сама возможность восстановить когерентность состояния после сбоя.
Для меня прокси как умственный констркут, позволяющий мыслить как операции работают, упрощают понимание сути.
Т.е. вместо того, чтобы мучиться рассуждениями как должен себя вести сервер при получении дубликатов — просто можно считать, что до сервера дубликаты не доходят, а этим занимается прокси. Иными словами, вместо одного сверхумного компонента, рассматриваем два простых — тупой сервер который умеет обрабатывать один запрос без повторов и кеш который тупо возвращает то что видел.

S>Вот у вас есть микросервис Х, который выставляет наружу некоторую операцию A.
S>Для выполнения этой операции нужно выполнить две операции — A1 и A2, в микросервисах Y и Z.
По-моему ты ожидаешь от идемпотентности больше, чем положено. Идемпотентность про одну операцию, а не про их взаимодействие. (вспомни формулу f ∘ f = f — там нет никаких A,Y,Z, ровно одна функция).

S>Для конкретики: А1 — это списание денег, А2 — резервирование авиабилета.
S>Z ничего не знает про деньги; его работа — чисто резервирование билетов от имени агента.
S>Y ничего не знает про билеты; его работа — чисто обработка платежей.
А это всё разруливается бизнес-логикой и универсального решения нет. Ну и CAP подлянки подстраивает.
Например, типично делают временную блокировку билета (скажем на 15 минут) в течение которой должна пройти успешно оплата. После этого уже резервирование билета.
Притом, в случае технической проблемы (всё упало, и после оплаты не удалось уложиться в 15 минут завершить резервацию), то предусматривают ручную утряску или возврат денег.