Привет, дорогой друг! ✋

Рады тебя встретить здесь!🥳 Очень классно, что ты пришёл на наш канал! На System Design огонёк среди таких же интересующихся темой прохождения интервью. На возможно лучший практический канал по подготовке к System Design интервью!🔥🏆

Архитектурная секция становится всё более популярной в нашей ITшной среде.
🚀 Хочешь прокачку по зарплате, должности, масштабу проекта?
➡ Нужно уметь пройти интервью.

Подготовится к прохождению без структуры и понимания что важно, а что нет нелегко и долго. Многие ресурсы рекомендуют тонны материала - книг, видеороликов, статей.📗📕🗞

Никто не может предугадать о чём спросит интервьюер. Поэтому стараются дать максимум. Пытаются в тебя впихнуть необъятное. А что из этого главнее? На что не стоит тратить время?

Вспомни вопрос из последнего собеседования. Очень вероятно, что он был неожиданным и новым.🤯

Бывает, в том же видеоролике или статье материал излагается не последовательно. Или явно пересказывается не знающим человеком. Или просто льётся вода💧. Так что знание в голове совсем не остаётся. Вот и потратили очередные 15 минут своей жизни на то что и не вспомнишь завтра😒

На нашем канале "System Design World" эксперты с реальным практическим опытом прохождения таких собеседований:
✅ Делятся актуальными на сегодняшний день советами
✅ Рассказывают про популярные архитектурные паттерны
✅ Расставляют акценты на том, что важно при текущем дизайне системе, а что можно опустить.

Мы это делаем потому что нам самим интересна эта тема☺ Нам доставляет радость делиться знаниями - выжимкой самого главного. И срезать ненужные куски теории там, где она не нужна. Теории, в которой можно потонуть, получить измученность от непонимания и минимальный выхлоп по применению знаний.

Изучая вместе с нами материал ты со временем будешь:
💡 иметь в голове основные архитектурные паттерны, приёмы проектирования
🌇 знать общую концепцию построения системы
💪 обладать уверенностью благодаря проводимым совместным дизайном сервисов и их частей.

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

Знания в голове копятся постепенно. Навык применения паттернов шлифуется со временем в более отточенный инструмент. Здесь важно усердие. Которое у тебя уже есть. Как это стало понятно? Ты дочитал до конца😊

🆙 Поэтому дерзай! Смотри предлагаемые ролики, заметки, разборы дизайнов. Задавай вопросы. Прокачивай свои прекрасные 🧠

Требования к системе - не просто звук.

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

В начале пути программиста я пропадал в статьях по языку, особенностям использования фич, изучению хороших и плохих практик. Тащился когда в реальном проекте реализовывал нужный функционал, активируя на 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