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

·>Не очень ясно причём тут идемпотентность тогда. Идемпотентность никак не помогает рассуждать о корректности взаимодействия между множеством систем, только между двумя. Именно между двумя системами происходит State Transfer.
Ну так у нас взаимодействие всегда происходит между двумя системами. Я же вроде очень подробно пример расписал. Непонятно, что вам непонятно

·>Так это уже CAP.
Нет. CAP — это некий удобный акроним, на который можно списать всё, что угодно. Утекли деньги со счёта — "это CAP виновата ". Нет, это так не работает.


·>Именно причём. У тебя происходит Partitioning (между клиентом и сервером произошел разрыв связи) и бизнес должен решить, чем жертвовать C или A.
Ок, я выбираю пожертвовать A (хотя это опять ложная дилемма — A не является бинарной величиной). Верните мне мою C.

·>Оплата прошла, билет куплен успешно. Если у клиент об этом не узнал (мобильник выпал из рук и разбился), то это забота клиента найти способ связаться и узнать о результате.
Не мобильник выпал и разбился, а VM была перезапущена в рамках стандартного failover. Клиент — это серверный процесс. Как именно вы предлагаетее ему "связаться и узнать о результатах"?

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