Парадайс))

Ок согласен.

Какая разница. Общее направление должен кто-то задать. Сказать менеджменту стоимость решения.

С другой стороны, выдав список доработок по каждой системе, солюшена вообще не заботит, кто там, как и что кодит

Сейчас читаю Клеппмана . Он в главе про репликацию в распределенных  системах баз данных без лидера рассматривает вопрос разрешения конфликтов записи  на основе оптимистических блокировок только .  Это выглядит странным. Ни одна знакомая реляционная база не использует такой подзод при записи/изменении . Все делают на основании locks? Ну да , в распределенных системах lock дорогой, но иначе это же не про консистентность? Неужели lock в распределенных системах настолько дорого ? Ну я в mongo не очень, но ведь в монго на основе локов?

Я с такими решениями не сталкивался.
Обычно решееия ее требуют 150 систем) космос какойто.
Но видимо вы там давно сидите.
Интересно как вам удается аргументировать повышение зп.
Ведь раз в 3 года вы беднеете на 25% примерно

Контору меняешь )

Ну DynamoDB, которая самая известная из таких СУБД, она eventually-consistent, да. Он в той же главе вроде много об этом пишет

Обычно надо пяток микросервисов понять влкруг и все
Такого чтобы понимать все это ж bad design.

Фича на 150систем - я бы подумал зачем так жить...

Блокировки - это уже не про доступность

без локов можно рассчитывать только на eventually consistent?

Не фича, а продукт

Ну вот и получили срок 3года
За этот срок вы ничего не поменяете и не улучшите 😈
Кодовую базу даже не поймете.

ну а какие локи могут быть, если мы не знаем (не хотим знать), сколько серверов у нас вообще живых в момент записи

Почему ? Доступность - это когда система ответит что-то, ведь так ?

Мы хотим. У нас же есть число нод -w,  которое должно подтвердить запись. Мы ждём их. Мы могли бы сначала ждать лок на w нодах

"When you request a strongly consistent read, DynamoDB returns a response with the most up-to-date data, reflecting the updates from all prior write operations that were successful. However, this consistency comes with some disadvantages:
   A strongly consistent read might not be available if there is a network delay or outage. In this case, DynamoDB may return a server error (HTTP 500).
   Strongly consistent reads may have higher latency than eventually consistent reads.
"

Если есть необходимость в локах, то мы должны обеспечить одновременное присутствие всех реплик. Иначе никак. Это это уже не высокая доступность

Не обязательно ведь всех , а только кворума ? Так ведь можно настроить и Кассандру и кафку. Ждём некое подмножество