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