Как я понял, наш коллега хочет CP систему (из CAP). Если система сильно-консистента, то у неё должен быть какой-то единый источник данных (ну вроде того). Этот источник данных может быть постгресом, редисом (какой-то бд), лидером выбранным при инициализации (или выбираемый консенсусом в кворуме) или детерменированным алгоритмом выбора ноды по username-у (что можно задать только при инициализации или консенсусом в кворуме).

Из конкретных решений, я бы тут выбрал лидера с хордом или redis. С etcd я никогда не работал, но насколько я понимаю, он сильно больше read чем write

Вариант с БД(k-v) мне больше нравится тем так как ее можно на нескольких нодах раскачать

Так если эти ноды сосплитятся - что делать будешь?

Типа мы не можем бороться с P, а постгрес такая волшебная может быть и C и A и P

ну вот etcd вроде это решает через рафт алгоритм

Ну тык он перестаёт быть C от этого

Ты же хочешь C

Ничего он не перестаёт

они пишут на сайте что 1000 врайтов в секунду

Да, я перепутал. Он все ещё не P

Системы где лидер выбирается консенсусом точно такие же CP как и где лидер выбирается при инициализации (как master-slave в PostrgeSQL)

В случае сплита кластера raft каждый выбирает себе лидера

Насколько я понял, в случае сплита etcd перестаёт работать, разве нет?

Если etcd работает во время сплита, то он не Strong Consistent

Так вообщем прошу прощения, понятие сплита похоже было применено мной не корректно. Ноды не знают ни чего друг о друге и не связанны. Под сплитом я имел введу обрыв одной из нод. Соответственно мне нужно CA так как P меня в принципи не волнует.

Слишком сложно, но походу на чтение продолжает работать..

Ты наивно думаешь что твои ноды не связаны, но на самом деле они связаны через ту базу данных, которую ты выберешь для этого kv

ну это да.