CAP-теорема и правило Клеппмана

Изучать хайлоад, системный дизайн, и не изучать распределенные системы нельзя. Изучать распределенные системы и не знать CAP-теорему как бы тоже нельзя. Но CAP-теорема с методической точки зрения - затратное и практически сомнительное занятие. Неуклюжее упражнение, имеющее мало общего с реальностью. Мы использовали такой “академический” подход: от CAP-теоремы переходили к её критике, и затем к BASE и PACELC. Но на это уходит чёртова куча времени! Что делать?

И я тут подумал, при всем моем уважении к системности и академичности, для большинства инженеров это вообще довольно бессмысленное занятие: тратить на эту муть условные полтора часа.

В то же время есть прекрасная статья Мартина Клеппмана, “Please stop calling databases CP or AP”. В ней есть несколько важных мыслей, но центральная следующая: Р – не опция, а необходимость. Нет ИТ-систем, в которых свойство P, “устойчивость к разделению” было бы опционально. Поэтому мы очень грубо всегда выбираем между С (согласованностью) и А (доступностью). А этот выбор уже понятен любому программисту, и методологически изучить это правило значительно проще и полезнее. И как будто его смело можно назвать “правилом Клеппмана”, а звучать оно должно так:

В современной распределенной ИТ-системе, устойчивой к потере связи между узлами, можно обеспечить либо согласованность либо доступность, но никак не всё вместе.

Короче, предлагается изучать просто “правило Клеппмана”, изучение CAP-теоремы и PACELC-классификации оставить только тем, кто интересуется этими вопросами достаточно глубоко.

Что думаете?

—
Наши ближайшие запуски:
3-е июня: Производительность и наблюдаемость бэкенда. Поиск проблем в продакшене (Михаил Курмаев, Т-Банк)
9-е июня: Redis и Valkey: от основ к хайлоаду (Константин Ратвин, МФТИ/Сбертех)
18-е июня: Docker и Kubernetes: основы разработки под облачную инфраструктуру (Николай Ихалайнен, MyDB)
30-е июня: Системный дизайн высоко-нагруженных проектов (Алексей Рыбак, devhands.io)