История изменений

Как-то всё выглядит наивно и по верхушкам.

Итак, начнём с идемпотентности - свойства запроса обладать возможностью быть исполненным несколько раз, и иметь эффект как от одного исполнения. Ценность в следующем - допустим, клиент производил запрос, и соединение оборвалось. Был запрос принят или нет - не понятно. Если клиент переводил на другой счёт деньги - может ли он обновить страницу и не бояться, что деньги спишутся дважды? Проще всего достижимо добавлением id запроса в его тело - если запрос уже был исполнен, операция не производится, и возвращается сохранённый результат.

И куда этот id девать? Что делать с ответом? Тут же миллион вопросов дальше.

Как достигнуть устойчивости? Имеем парк серверов, каждый из них выполняет свою операцию, с возможностью её отменить - их необходимо координировать в условиях риска выхода из строя серверов, ПО и сети. При выходе из строя сервера необходимо, чтобы он возобновил исполнение присвоенных ему операций - нужно сохранять их в реплицированную БД. Кажется, любая простая БД типа Ключ-Значение подойдёт. Когда исполнение возобновится - оно должно продолжить с момента последней транзакции в цепочке - то есть после каждой транзакции в цепочке, промежуточное состояние должно сохраняться в БД - с возможностью возобновления операции другим исполнителем.

Какой ещё парк серверов? Какие ещё операции? Все давно сидят на кубернетесе.

Если по теме - для этого надо несколько книг написать и то всё будет поверхностно, смысла обсуждать такую широчайшую тему не вижу. Тут какая-то каша и всё в куче.

Как-то всё выглядит наивно и по верхушкам.

Итак, начнём с идемпотентности - свойства запроса обладать возможностью быть исполненным несколько раз, и иметь эффект как от одного исполнения. Ценность в следующем - допустим, клиент производил запрос, и соединение оборвалось. Был запрос принят или нет - не понятно. Если клиент переводил на другой счёт деньги - может ли он обновить страницу и не бояться, что деньги спишутся дважды? Проще всего достижимо добавлением id запроса в его тело - если запрос уже был исполнен, операция не производится, и возвращается сохранённый результат.

И куда этот id девать? Что делать с ответом? Тут же миллион вопросов дальше.

Как достигнуть устойчивости? Имеем парк серверов, каждый из них выполняет свою операцию, с возможностью её отменить - их необходимо координировать в условиях риска выхода из строя серверов, ПО и сети. При выходе из строя сервера необходимо, чтобы он возобновил исполнение присвоенных ему операций - нужно сохранять их в реплицированную БД. Кажется, любая простая БД типа Ключ-Значение подойдёт. Когда исполнение возобновится - оно должно продолжить с момента последней транзакции в цепочке - то есть после каждой транзакции в цепочке, промежуточное состояние должно сохраняться в БД - с возможностью возобновления операции другим исполнителем.

Какой ещё парк серверов? Какие ещё операции? Все давно сидят на кубернетесе.

Если по теме - для этого надо несколько книг написать и то всё будет поверхностно, смысла обсуждать такую широчайшую тему не вижу.