Нельзя пожертвовать устойчивостью к разделению

Отличная статья, которая показывает, почему теорема CAP на самом деле сводится к выбору между двумя вариантами: Consistency или Availability.

Автор лихо заходит в тему, проезжаясь катком по разработчикам БД, которые позиционируют свои продукты как CA (без Partition Tolerance). По его мнению, они просто не понимают теорему CAP.

⭐️ Интересные идеи

➡️ Настоящая консистентность (которую правильнее назвать линеаризуемостью) недостижима, потому что всегда существует небольшой лаг репликации. Всё, что мы можем сделать в реальности — это уменьшить этот лаг до такой величины, которой можно пренебречь.

➡️ У доступности тоже есть ограничения. Если у вас есть 5 узлов с данными и по какой-то причине все узлы отвалятся, вы потеряете данные. Так что бесконечная доступность — тоже скорее фантастика.

➡️ Устойчивостью к разделению можно пожертвовать только в одном случае: если есть гарантия того, что сеть абсолютно надёжна и ни один узел никогда не умрёт (ха-ха).

➡️ Если один узел работает с надёжностью 99,9%, то кластер из 40 таких узлов будет иметь надёжность 96,1%. Это означает, что с вероятностью в 4% что-то пойдёт не так. И в такой ситуации системе придётся жертвовать либо согласованностью, либо доступностью.

➡️ Но обычно распределённым системам и не нужна идеальная согласованность или абсолютная доступность. Поэтому лучше сосредоточиться на том, чтобы проектировать системы с учётом компромиссов, а не спорить о теоремах.

➡️ В качестве альтернативы автор предлагает рассмотреть две метрики: процент запросов, на которые получен успешный ответ, и процент необходимых данных, включённых в ответ. Чем-то из этого можно пожертвовать при проектировании системы.

Приятного чтения!

➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи