https://youtu.be/bPuJ-BaIOs0
О дивный новый мир System Design.

Идеальное место для познания мудрости по созданию архитектурных систем. Направимся туда для улучшения наших знаний и навыков.

#SystemHold

https://youtu.be/K_cyBzDSGs4

Мир SystemHold оказался не таким радужным. Более того, Мастер Неба попросил нас о помощи с восстановлением их облачного сервиса. Я думаю, что помочь мы сможем. Для начала вспомним о требованиях, предъявляемых при разработке системы.

Начнём со Scalability/Масштабируемости.

Нефункциональное требование "Доступность" необходимо как воздух каждому сервису.

Availability

Телеграмм не подключается❗Висит загрузка. Волнительно. Неприятно. Снижается удовлетворенность пользователей от использования сервиса.

Реклама не показывается. Трафик падает. Акционеры в панике скидывают акции 📉. Совет директоров вызывает главного архитектора.
СВ: "Что происходит, дорогой?"
А: "Доброе утро. Зачем меня разбудили так рано?"
СВ: "Посмотри новости."
А: "А, так это плановые ночные работы на нашем единственном сервере с небольшим downtime."
СВ: "😳"
СВ: "Это не допустимо!"
А: "Почему?"
СВ: "Мы теряем деньги. Нам нужна доступность 24/7 !"
А: "Такого требования при проектирование системы не было 🤷"
Архитектор медленно наливает горячий шоколад, разворачивается и идёт в своей пижаме в сторону лифта.

В современном мире всё должно быть доступно:
1) Сотрудник в течение рабочего дня для решения вопросов;
2) Чайник для заваривания крепкого бодрящего чая когда захотелось его попить;
3) Сервис доставки еды для вкусного обеда;
Я хочу зайти в телеграмм нажатием по значку в телефоне или кликом мышки на ПК и через 0.5 секунды увидеть состояние диалогов и чатов.

С точки зрения разработки архитектуры Availability / Доступность значит многое:
1) Система продолжает функционировать даже при падение критического компонента;
2) Система обрабатывает ошибки компонентов без нарушения обработки запросов;
3) У критически важных компонентов должны быть реплики-дублирующие компоненты;
4) Существует мониторинг, который помогает быстро обнаруживать проблемы;
5) Есть возможность быстрого отката функционала;
6) Отсутствует единая точка отказа;
7) Система справляется с быстрорастущим трафиком;
8) Система переживает сбои сети, софт, железа;

2 популярных паттерна для реализации этого требования:
1) Replica - дублирующий компонент c разными вариантами записи, чтения типа master/slave
К примеру, реплицируем БД. Запрос от клиента приходит в master. Master скидывает в slave. Если режим записи синхронный, то ответим клиенту только после записи в slave.
2) Failover - дублирующий компонент готов к обработке текущего трафика.
a) Стратегия active-active. Оба обрабатывают текущий трафик.
b) Стратегия active-passive(standby). Failover мониторит состояние active инстанца. При его падение берёт трафик на себя.

Пример реализации этого паттерна в nginx.

В этом посте про "Доступность" сервиса мы разобрали:
1) Мотивацию использования этого нефункционального требования;
2) Его основные характеристики;
3) 2 паттерна для реализации требования в системе.

Удачи в построение отказоустойчивых систем!

#Requirements #Availability #Replica #Failover

Availability

Подкрепим текстовую информацию видеорядом 🧑‍💻
Создал видеоролик, в котором реализуем нефункциональное требование "Доступности" для небольшого сервиса.

https://youtu.be/qCp-2Cyu4MY

Успешный алгоритм прохождения интервью. Какой он?

🔥 Интервью - это стресс.
Как сделать прохождение комфортным?

💡 Хорошисты и отличники обладают хорошей базой знаний.
Однако этого ещё не достаточно, чтобы успешно пройти специальный экзамен - ЕГЭ. Его специфика породила определённую подготовку. Одно дело знать, другое - уметь применить знания по определенной теме за короткое время в данных условиях.

Слышал истории, когда люди полгода готовились к интервью изучая разрозненный материал. И не факт, что проходили🤷
Предлагаю рассмотреть саму структуру интервью и уменьшить тем самым неопределенность и стресс от прохождения.

⚡️ Структуру задает кандидат. Хорошо когда она есть. И ещё лучше когда шаги в ней последовательные и логичные. Помогают кандидату двигаться в бодром темпе и не упускать главные моменты.

⚙️ Существуют различные варианты таких шагов. Мне понравился подход Александра. Он драйвит тему интервью. Можно сказать, формирует тренд.

1️⃣ В начале кандидат задаёт уточняющие вопросы, понимает границы системы. Таким образом, синхронизируется с интервьюером.
2️⃣ И далее уже от общего к частному строит систему по шагам.

✅ Поняв и проработав предлагаемую структуру, можно смело пробоваться в наши и зарубежные Big Tech компании.

#SystemDesignInterview #SystemDesign

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

"История одной капчи" или...