Consistency

❗ На собеседованиях System Design самый распространенный тип согласованности, которую просят реализовать - "Eventual consistency" - "Согласованность в конечном счёте".

🕐 Когда изменённые на одной ноде данные спустя какое-то время оказываются и на остальных. Пример системы - лента друзей. По слухам, её просят реализовать в 70% случаев на собеседованиях в одну из Top Tech RU компаний.

⚡ В самом начале изучения System Design мне было не просто настроить мозги на что-то кроме Strong Consistency. Когда есть обычный сервис, который общается с обычной БД рядом. И нет никакой распределенности по планете.

🚣‍♀️🚣‍♂️ По дефолту все запросы сериализуются и не конфликтуют когда работаем не изменяя уровень изолированности в БД.

➡ Дела обстоят иначе с появлением распределенности и высоких нагрузок. Клиентские запросы попадают на сервера в разные ЦОДы. Появляются многочисленные параллельные операции записи, чтения. По теореме CAP нам уже нужно выбрать что реализуем в придачу к P:
❇ Availability
или
❇ Consistency

Если нужно видеть одно и тоже значение данных в любой момент времени на любой ноде, нам нужна "Strong Consistency". Необходимы:
1) синхронные операции репликации
2) разрешение конфликтов записи
Такое требование к согласованности данных можно предъявить к созданию, например, банковской системы.

💰⚠ Здесь точность операций с балансом - наше всё. Допустим, по счёту нельзя уйти в минус. Две параллельные операции на две мастер ноды обязательно должны синхронизироваться с разрешением конфликта, чтобы не разъехался баланс.
При этом теряется доступность - ждать ответа приходится долго.

🌠 Можно пожертвовать такой синхронизацией. Для ленты друзей сойдёт и согласованность в конечном счёте. Пост от одного мастера не сейчас, но вскоре долетит до другого. И далее добавится в новостную ленту пользователя. Это уже больше походит на AP систему. Можно делать пост и не ждать обновления ленты у всех друзей, чтобы пользователю вернулось "Ваш пост опубликован и сейчас уже отображён у каждого друга в ленте".
Улучшилась доступность сервиса.

📍 Существуют и более тонкие градации Согласованности. Здесь я отметил два крайних уровня, чтобы в целом осознать это нефункциональное требование "Согласованности данных".

#Requirements
https://youtu.be/nRtLkptDSxE