Их просто надо понять.

В начале пути программиста я пропадал в статьях по языку, особенностям использования фич, изучению хороших и плохих практик. Тащился когда в реальном проекте реализовывал нужный функционал, активируя на 100% свою нейросеть.

Я смотрел на классы, функции, взаимодействия. Строил для себя образ проекта. И думал, что очередная написанная мною функция - это самое главное❗

Как-то работал в компании, которая занимается генерацией и квантовой передачей ключа. Появился партнёр из Южной Кореи и, соответственно, задача по созданию внешнего api для интеграции. Это была пилотная версия. До этого мы не могли интегрироваться по интернету. Были лишь локальные протоколы для сопряжения нашей железки и рядом стоящих шифраторов.

Прикинули типы и содержание http запросов. Этим, фактически, установили функциональные требования к системе. Нужно было выбрать библиотеку для реализации http интерфейса.
Составил excel табличку, заполнил по следующим критериям:
✅ Удобство пользования
✅ Поддержка от авторов/сообщества
✅ Функционал
✅ Скорость работы
Проанализировали командой результаты, выбрали.

Далее я стал реализовывать нужные классы с нужной обработкой, генерировать rpc(у нас был thrift) для связи с ядром системы. Всё было готово и протестировано. Партнёр мог забирать ключ по http запросу.

Моя работа была сделана. И я был ей доволен. Считал что сделал самое важное. 🥳

Сейчас же я понимаю, что работающая система > работающей функции. И важнее. Если ты смотришь на функционирование всей системы в целом.

Тогда был ещё специалист, который следил за всей сетевой инфраструктурой, фаерволом. Он обеспечивал связь внешний ip <-> внутренний ip железки. В случае отказа работы железки мы бы включили другую и специалист изменил бы маппинг. Пускай так. С зачатком автоматики процесса. Но это уже что-то.

Этим мы обеспечивали Availability/Доступность сервиса. Можно сказать, что специалист был Proxy/Load Balancer'ом. А наша вторая железка на подхвате - failover. Получается, что у системы мог быть определенный downtime из-за выхода из строя главной железки master. downtime мог также случится из-за отказа любой части сетевого оборудования на пути следования пакетов.

Протокол был https. Я генерировал, подписывал, отсылал сертификаты. То есть, мы ещё обеспечивали требование Security в плане прав доступа.
Могли бы ещё определять группы пользователей - сколько для пользователя данной группы доступно ключа в единицу времени. Определять стратегии, политики.

На этом примере я хотел показать, что изначально требования могут быть и не заданы явно. Что просто делаешь по наитию нужные вещи. И сам того не замечая реализуешь какие-то требования(их содержание).

А по мере погружения в System Design начинаешь подмечать больше. Размышляешь о том, как работает система целиком, насколько устойчива к падениям, обрывам, перегрузкам. Сознательно задумываешься о выделение каких-то основных требований(желательно до проектирования системы). И тогда уже можешь донести оформленные мысли коллегам, руководству и улучшить саму систему 💪

#Requirements

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