Что такое CAP-теорема и как она влияет на распределенные системы
Что проверяют
Умеете ли вы переводить теорему в проектные решения. Формулировку называют почти все, поэтому интервьюер обычно сразу спрашивает, как выбор отражается на вашем сервисе: что показать пользователю, когда реплика отстала, и как не создать дубль при повторной доставке сообщения.
Как отвечать
Суть в одном предложении: во время сетевого разрыва между узлами приходится выбирать между отказом в обслуживании и ответом на потенциально устаревших данных. Устойчивость к разделению при этом не опция, сеть рвётся независимо от вашего желания.
Дальше сразу к последствиям для системы:
- деньги, остатки товара, бронирование мест: выбирают согласованность, ошибка лучше, чем две продажи одного места;
- лента, поиск, счётчики просмотров, рекомендации: выбирают доступность, устаревшее значение приемлемо.
Хорошо назвать приёмы, которыми живут с отставанием. Чтение из реплики, но в течение короткого окна после своей записи читаем с основного узла, иначе пользователь не увидит собственное изменение. Идемпотентные обработчики с ключом операции, потому что брокеры дают доставку не менее одного раза. Отправка событий через outbox в одной транзакции с бизнес-записью, иначе запись и сообщение разъезжаются. Компенсирующие действия вместо распределённой транзакции. В конце уместно упомянуть PACELC: вне разрыва выбор идёт между задержкой и свежестью данных.
Где спотыкаются
Определяют согласованность как «на всех узлах одинаковые данные». В теореме речь про наблюдателя, который видит единственную актуальную копию, и без разрыва система спокойно бывает одновременно доступной и согласованной.
Говорят, что выбрали доступность, и на этом останавливаются. Проектное решение это описание поведения: показать прежнее значение с пометкой о задержке, принять запись в очередь и подтвердить позже, отклонить операцию. Без этого ответ остаётся пересказом определения.
Считают, что очередь снимает вопрос согласованности. Она его переносит в обработчик: появляются дубли, нарушается порядок, событие приходит раньше, чем реплика увидела строку. Отсюда и требования к обработчику: идемпотентность, версия сущности, повтор с задержкой.