CAP и PACELC, уровни согласованности, CQRS и Event Sourcing.
Практика. Для пяти функций маркетплейса определить, где нужна сильная согласованность, а где достаточно итоговой.
Практика. Спроектировать модуль с CQRS (запись и проекции для чтения) и описать задержку согласования и её влияние на пользователя.
C — согласованность (каждое чтение видит последнюю запись), A — доступность (каждый запрос получает ответ), P — устойчивость к разделению сети.
При разделении сети (P) распределённая система выбирает: отвечать, рискуя отдать устаревшее (A), или отказать, сохранив согласованность (C).
Не нужно в CRUD-домене, при требовании немедленной согласованности и без опыта эксплуатации асинхронных конвейеров. Вводить по нарастающей и точечно.
Команды меняют состояние, запросы возвращают данные — и модели для них разные.
Если записи прекратятся, все реплики со временем придут к одному значению. Сразу после записи разные клиенты могут видеть разное.
Кворум гарантирует свежесть, но не порядок: прерванные и конкурентные записи, а также нестрогий кворум ломают линеаризуемость.
Точная формулировка CAP и типичные искажения, неизбежность разделения и выбор C/A по операции, спектр согласованности и сессионные гарантии, кворумы N/R/W и их пределы, PACELC и разрешение конфликтов.
Разделение моделей чтения и записи, цена рассинхронизации, событие как источник истины, снапшоты и версионирование событий, и честный ответ на вопрос «когда это не нужно».
На живом собеседовании sotto слышит вопрос интервьюера и показывает короткий ответ и план. Оставьте контакт — пришлём доступ и промокод.
sotto