Ладно, давай без лишних сложностей. Используй проверенный механизм консенсуса – Raft или Paxos – чтобы поддерживать кластер в синхронизации. Обрабатывай каждую запись как запись в журнале, реплицируй её на большинство узлов и фиксируй только после подтверждения кворума. Это даст тебе согласованность (P) и устойчивость к разделению (C), но придётся пожертвовать задержкой (A). Что касается самих данных, используй журнал, в который можно только добавлять записи, или хранилище ключ-значение, которое записывает на диск, а затем передаёт репликам. Пусть коэффициент репликации будет нечётным — три вполне безопасно – чтобы можно было потерять один узел и остаться онлайн. Если нужна более высокая доступность, добавь отдельный уровень только для чтения, который будет зеркалировать основной узел записи, но помни, что даже при чтении нужно, чтобы транзакции проходили через кворум для поддержания согласованности. И наконец, настрои автоматические проверки работоспособности и выборы лидера, чтобы системе не нужен был человек, чтобы за ней присматривал. Это основа; теперь продумай детали, исходя из твоих конкретных требований к согласованности и задержке.

Звучит отлично. Если планируешь микс с большим количеством записи, держи write-лог на быстром SSD и используй асинхронное реплицирование для массовых операций, но не забывай, что синхронные подтверждения для каждой транзакции всё равно пишутся в лог. Для нагрузки, где преобладает чтение, поможет отдельный tier только для чтения, но помни, что эти чтения всё равно должны попадать под quorum, если нужна строгая консистентность. Следи за лидером, держи горячий запас готовым, и если нагрузка подскочит, запускай быструю ротацию лидера. Оптимизируй логику пакетной обработки и чисти лог-файлы – никакой лишней нагрузки.

Добавь задание на сжатие, чтобы запускалось, когда лог достигнет порогового значения, иначе старые записи будут накапливаться. Следи, чтобы сердцебиение было стабильным – если узел пропустил его, выкинь его до того, как лидеру станет слишком много работы. И обязательно ограничь размер буфера асинхронной репликации; иначе он переполнится, и мы вернёмся к синхронному режиму, а задержка подскочит. И ещё подумай о read-repair: время от времени заставляй только-для-чтения узлы сверяться с лидером, чтобы не накапливать расхождения. Это последний уровень защиты.

Поняла — жёсткий цикл, да. Просто держи метрики в курсе, и ты не отстанешь. Удачи.