Start free

Get App

Home
/
Transcripts
/
Career & Job Search
/
System Design: Что на самом деле проверяют на интервью? — Transcript

System Design: Что на самом деле проверяют на интервью?

Видео объясняет, что проверяют на интервью по системному дизайну, разбирает примеры и даёт советы для уровня Middle Plus.

Key Takeaways

Плохой системный дизайн может привести к серьёзным финансовым и репутационным потерям.
System Design — обязательный этап интервью для Middle Plus и выше в современных IT-компаниях.
Важно уметь формализовать требования и обсуждать архитектурные компромиссы.
Знания системного дизайна нужны не только бэкендерам, но и фронтенд, мобильным разработчикам и менеджерам.
Практика и понимание основных концепций системного дизайна критичны для успешного прохождения интервью.

What the video covers

Разбор примера крупного сбоя Slack из-за плохого системного дизайна и его последствий.
Объяснение важности этапа System Design на технических интервью, особенно для уровня Middle Plus.
Пояснение, что системный дизайн — это проектирование ПО и инфраструктуры с учётом масштабируемости, надёжности и безопасности.
Рассмотрение требований к системам: функциональные и нефункциональные.
Примеры архитектурных решений, включая монолиты и микросервисы.
Обсуждение компромиссов в архитектуре и важности понимания trade-off.
Советы по подготовке к интервью и практическим заданиям по системному дизайну.
Роль системного дизайна для разных специалистов: фронтенд, мобильные разработчики, тимлиды, девопсы.
Выбор технологий и инструментов под конкретные задачи.
Подчёркивание важности отказоустойчивости, масштабируемости и безопасности систем.

Chapters

Что такое системный дизайн и зачем он нужен на интервью?

Системный дизайн — это процесс проектирования программного обеспечения и инфраструктуры с учётом масштабируемости, надёжности и безопасности. На интервью он проверяет умение кандидата формализовать требования, принимать архитектурные решения и учитывать компромиссы.

Какие ошибки в системном дизайне могут привести к серьёзным последствиям?

Ошибки, такие как централизованная архитектура, неравномерное распределение нагрузки и недооценка рисков перегрузки компонентов, могут привести к сбоям, финансовым потерям и падению акций компании, как это было в случае Slack.

Кому полезно смотреть это видео?

Видео полезно разработчикам уровня Middle Plus, архитекторам, тимлидам, девопсам, аналитикам, а также фронтенд и мобильным разработчикам, которые работают с распределёнными системами и хотят улучшить навыки системного дизайна.

Full Transcript — Download SRT & Markdown

00:00

Speaker A

Наверняка ты знаком со Slack. Это такой мессенджер, который крупные компании типа OpenAI и Spotify используют для коммуникации внутри. Но слышал ли ты о том, как плохой системный дизайн привёл к падению акции Slack на 14%, сколько?

00:16

Speaker A

И квартальной выручки на 5%. 29 июля девятнадцатого года СЛАК пережил крупный технический сбой. более 2 часов клиенты и компании по всему миру не могли отправлять и принимать сообщения. В итоге Слак потратили около 8,2 млн долларов на компенсации своим клиентам.

00:36

Speaker A

И квартальной выручки на 5%. 29 июля девятнадцатого года Slack пережил крупный технический сбой. Более 2 часов клиенты и компании по всему миру не могли отправлять и принимать сообщения. В итоге Slack потратил около 8,2 млн долларов на компенсации своим клиентам.

00:45

Speaker A

Во-вторых, нагрузка на базы данных была распределена неравномерно. В-третьих, были недооценены риски перегрузки отдельных компонентов, которые потянули вслед за собой вниз остальные сервисы.

00:57

Speaker A

Причины сбоя крылись в неудачных архитектурных решениях. Во-первых, из-за централизованной архитектуры была затронута большая часть пользователей.

01:15

Speaker A

Middle Plus наравне с поведенческим интервью и кодингом. Потихоньку этот тренд подхватывают и сНГшные компании, добавляя этап System Design для большинства направлений наряду с другими техническими этапами. По сути, тебе дают задачу типа: "Спроектируй систему уведомлений для Тиндера", и ты рисуешь

01:36

Speaker A

Во-вторых, нагрузка на базы данных была распределена неравномерно. В-третьих, были недооценены риски перегрузки отдельных компонентов, которые потянули вслед за собой вниз остальные сервисы.

01:49

Speaker A

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

01:57

Speaker A

Наконец, система просто не умела работать в ограниченном режиме. Даже в успешном сервисе небольшой перекос в архитектуре может стоить миллионов долларов за несколько часов. И в этом видео ты узнаешь, как этого избежать. ФА уже давным-давно добавил секцию System Design и интервью для всех сотрудников

02:17

Speaker A

наконец, какие подходы и технологии применимы конкретно к этой задаче. Поэтому научите меня системному дизайну.

02:25

Speaker A

Middle Plus наравне с поведенческим интервью и кодингом. Потихоньку этот тренд подхватывают и СНГ-шные компании, добавляя этап System Design для большинства направлений наряду с другими техническими этапами. По сути, тебе дают задачу типа: "Спроектируй систему уведомлений для Тиндера", и ты рисуешь

02:42

Speaker A

ждёт на собеседованиях на уровень middle Plus - это те твои запросы, которые мы закроем в сегодняшнем видео. Тебе точно будет полезно это видео, и его рекомендуется досмотреть, не откладывая в долгий ящик, если ты относишься к следующим людям. Все ээ-разработчики,

03:01

Speaker A

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

03:20

Speaker A

поможем лучше формализовывать требования и взаимодействовать с архитектурой проекта. И наконец, а вы думали, я вас пропущу? FRНEND и mobile разработчики, вы тоже работаете с AP и распределёнными системами. Вам нужно масштабировать ваши продукты и приложения. И поэтому сейчас вам может попасться systemдизаign

03:40

Speaker A

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

03:55

Speaker A

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

04:07

Speaker A

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

04:24

Speaker A

готовишься к интервью или хочешь применять эти знания в будущем, в реальной работе, то рекомендуется их не пропускать и попрактиковаться. Немного об авторах курса перед тем, как мы начнём. Это Senor Goвелоopпер, который строил архитектуру в Авито. Senor Backend developпер, старший системный

04:42

Speaker A

наконец, какие подходы и технологии применимы конкретно к этой задаче. Поэтому научите меня системному дизайну.

04:58

Speaker A

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

05:19

Speaker A

Это запрос, который почти никогда не возникает отдельно, но при этом почти всегда всплывает в ходе работы с нашими менторами. Проблемы с процессами на разных стадиях разработки, кривая архитектура сервиса, невозможность масштабироваться. В конце концов, system design интервью, которое тебя

05:32

Speaker A

Прикладное значение системного дизайна в разработке достаточно очевидно. Он помогает создавать более эффективные и устойчивые решения, которые легко масштабируются и удовлетворяют запросом бизнеса и пользователей. Например, когда Amazon начали показывать стабильный рост пользователей заказов, они столкнулись с ограничением. Их старый монолитный сайт

05:54

Speaker A

ждёт на собеседованиях на уровень Middle Plus — это те твои запросы, которые мы закроем в сегодняшнем видео. Тебе точно будет полезно это видео, и его рекомендуется досмотреть, не откладывая в долгий ящик, если ты относишься к следующим людям. Все эй-разработчики,

06:03

Speaker A

Amazon сделал следующее. Разделил систему на несколько независимых сервисов. В дальнейшем это начали называть микросервисной архитектурой.

06:12

Speaker A

претендующие на уровень Middle Plus, у вас это точно спросят, даже если это не понадобится в работе. Архитекторы, тимлиды и менеджеры. Это поможет при проектировании систем и принятии архитектурных решений. Девопсы и сэры — мы поможем в понимании отказоустойчивости и масштабировании. Аналитики, вам мы

06:35

Speaker A

На этом этапе мы определяем, что именно нужно системе. Сами требования делятся на функциональные и нефункциональные.

06:43

Speaker A

поможем лучше формализовывать требования и взаимодействовать с архитектурой проекта. И наконец, а вы думали, я вас пропущу? Frontend и mobile разработчики, вы тоже работаете с API и распределёнными системами. Вам нужно масштабировать ваши продукты и приложения. И поэтому сейчас вам может попасться system design

07:04

Speaker A

обычно отвечают на вопросы, насколько удобно, быстро, надёжно что-то происходит. Для такого онлайн-сервиса по выгуливанию котов требования могли бы быть такими. Система должна обрабатывать до 10.000 одновременных запросов от пользователей, должна поддерживать рост пользователей до миллиона без перезапуска сервисов и должна быть

07:25

Speaker A

интервью, даже учитывая то, что вы как бы за фронт отвечаете. И увы, но ответ: "Да я как бы мобильщик, я в бэкэнде не секу" не прокатит, вы просто получите отказ. Именно поэтому мы построили видео следующим образом. Сначала идёт

07:45

Speaker A

пользователь взаимодействует с фронтэндом. Фронтнд отправляет запросы через API к микросервису. Тот общается с базой или кэшем и возвращает обратно через API ответ на фнENд, и пользователь его получает. Выбор технологий. На этом этапе мы выбираем конкретные инструменты под нашу задачу, чтобы детализировать

08:06

Speaker A

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

08:21

Speaker A

Например, мы можем решить, что наш бэкэнд будет на GO, frontend на Viewgjs, и базу мы выберем Postgress.

08:27

Speaker A

Это будет полезно для общего контекста, будущим лидерам и менеджерам. Но если ты хочешь только для тебя контент, открывай тайм-коды и переходи к интересующей тебя главе. Мы добавили домашки для отработки навыков. Ты, конечно, можешь сказать: "Я всё знаю, мне это не нужно". Но если ты

08:47

Speaker A

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

08:58

Speaker A

готовишься к интервью или хочешь применять эти знания в будущем, в реальной работе, то рекомендуется их не пропускать и попрактиковаться. Немного об авторах курса перед тем, как мы начнём. Это Senior Go developer, который строил архитектуру в Авито. Senior Backend developer, старший системный

09:13

Speaker A

Производительность. Тут всё просто. Система должна отвечать быстро и эффективно расходовать ресурсы. Например, часто запрашиваемые данные, в нашем случае история заказов, могут храниться в кэше. Это поможет сократить издержки. Управление данными. Здесь мы решаем, как храним, обрабатываем и защищаем наши данные. Все

09:34

Speaker A

аналитик из Альфа-Банка, эй-разработчик из одного большого классифайда, тех из Premiere One и, конечно, ваш покорный слуга Волк AK Антон Назаров, iOS разработчик из Apple.

09:53

Speaker A

Наблюдаемость. Здесь мы говорим о том, как контролируем работу системы. Пространство для действий здесь довольно большое, вплоть до того, что мы можем настроить Telegram-бота, который будет присылать нам уведомления о том, что у нас ошибка там или что-то упало.

10:09

Speaker A

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

10:33

Speaker A

UML-диаграммы или RFC или простой онбординг для новых разработчиков. На самом деле, в других источниках можно найти отличающийся перечень, который часто не включает тестирование и документирование. Мы взяли исчерпывающий перечень, который включал в себя процессные шаги из первых трёх пунктов и

10:54

Speaker A

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

11:10

Speaker A

огромного списка становится понятно, что в проектировании и реализации системы задействован не один архитектор или DevObs, но разные участники команды разработки, потому что некоторые этапы почти целиком завязаны на фронте, другие на бэкэндере, третье на тестировщике и так далее. Про снятие требований

11:30

Speaker A

Прикладное значение системного дизайна в разработке достаточно очевидно. Он помогает создавать более эффективные и устойчивые решения, которые легко масштабируются и удовлетворяют запросам бизнеса и пользователей. Например, когда Amazon начали показывать стабильный рост пользователей и заказов, они столкнулись с ограничением. Их старый монолитный сайт

11:45

Speaker A

муть нужна, есть простой продакшн пример. Ещё до покупкой ватсаппа всякими террористическими экстремистскими организациями ходила легенда, и СМИ активно рассказывали про то, что WhatsApp сервис сотнями миллионов пользователей по всему миру, поддерживается небольшой командой, всего из пятидесяти инженеров. То же самое

12:08

Speaker A

перестал справляться с нагрузкой. Возникло новое бизнес-требование: устойчивость и масштабируемость системы при нагрузках в миллионы пользователей.

12:27

Speaker A

легенда про то, как хороший системный дизайн и грамотный подход к разработке позволяет поддерживать такие огромные продукты на плаву малыми силами сплочённой команды. Но важно понимать исторический контекст. Сегодня WhatsApp - это уже совсем другой мессенджер с кучей функций, голосовых сообщений,

12:45

Speaker A

Amazon сделал следующее. Разделил систему на несколько независимых сервисов. В дальнейшем это начали называть микросервисной архитектурой.

13:03

Speaker A

что хранит сообщения в распределённой системе, доставляет их с минимальной задержкой даже при плохом интернете, обеспечивает надёжность доставки.

13:12

Speaker A

Построил масштабируемые базы и очереди и уделил отдельное внимание обеспечению отказоустойчивости и надёжности. Amazon не просто выдержали рост, они превратили свои наработки в отдельный бизнес ABC, который сейчас приносит десятки миллиардов долларов. А теперь подробнее разберём каждый компонент системного дизайна в разработке. Сбор требований.

13:33

Speaker A

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

13:51

Speaker A

На этом этапе мы определяем, что именно нужно системе. Сами требования делятся на функциональные и нефункциональные.

14:10

Speaker A

чтобы они действительно были тебе полезны по ходу интервью, можно посмотреть по ссылке в описании на моём бусте. А перед тем, как мы перейдём к основам проектирования систем, маленький интерактив. Напиши, пожалуйста, в комментарии, приходилось ли тебе уже сталкиваться с System designw, что это

14:29

Speaker A

Функциональные требования — это то, что система должна делать, какие функции предоставлять своему пользователю. Для абстрактного онлайн-сервиса выгула котов — это функции бронирования, уведомления о начале и завершении прогулки. Нефункциональные требования — это качество системы, то есть как она выполняет свои функции. Эти требования

14:42

Speaker A

это видео, поставь, пожалуйста, лайк и подпишись на канал. Впереди ещё очень много образовательных проектов, полные гайды, курсы и всё-всё-всё. Очень не хочется, чтобы ты это пропустил.

14:59

Speaker A

обычно отвечают на вопросы, насколько удобно, быстро, надёжно что-то происходит. Для такого онлайн-сервиса по выгуливанию котов требования могли бы быть такими. Система должна обрабатывать до 10 000 одновременных запросов от пользователей, должна поддерживать рост пользователей до миллиона без перезапуска сервисов и должна быть

15:10

Speaker A

Проектирование системы начинается от взаимодействия пользователя и до ответа сервера и до его способности выдерживать рост. Для наглядности разберём с вами продукт сервиса аренды самокатов, например, Bush, Urent или Яндек Go.

15:24

Speaker A

возможность интегрировать внешние API карт. Второй этап — архитектура системы. Здесь мы показываем общую схему, какие компоненты будут в системе и как они будут связаны. Эта схема показывает, как система устроена, чтобы выполнять функции и соответствовать нефункциональным требованиям. Например, здесь мы можем показать, как

15:37

Speaker A

Когда вы приступаете к проектированию, важно выбрать не технологии, а именно характер будущего продукта. Речь идёт не о том, насколько хорошо вы напишите, э, ваш ээнд, а о том, насколько ваш продукт будет безопасным, устойчивым и быстрым.

15:52

Speaker A

пользователь взаимодействует с фронтендом. Фронтенд отправляет запросы через API к микросервису. Тот общается с базой или кэшем и возвращает обратно через API ответ на фронтенд, и пользователь его получает. Выбор технологий. На этом этапе мы выбираем конкретные инструменты под нашу задачу, чтобы детализировать

16:09

Speaker A

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

16:25

Speaker A

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

16:42

Speaker A

Следующее свойство - это производительность. Всё должно быть быстро, то есть отклик сервера должен быть мгновенным. Надёжность. Данные о поездках и оплате должны храниться в базе данных. В случае, если пользователь оплатил свою поездку, то она никак не должна у нас исчезнуть из базы данных.

16:59

Speaker A

Например, мы можем решить, что наш бэкэнд будет на Go, frontend на Vue.js, и базу мы выберем Postgres.

17:09

Speaker A

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

17:25

Speaker A

Масштабируемость. Теперь мы переходим к качествам системы. Масштабируемость нужна для того, чтобы наша система выдержала рост нагрузки. Например, с...

17:44

Speaker A

суть системного дизайна. Следующая тема, на которую мы с вами поговорим - это требования к системе.

17:51

Speaker A

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

18:07

Speaker A

именно требования мы будем собирать. Видов требований на самом деле существует великое множество, но самые основные - это функциональные и нефункциональные требования. К функциональным требованиям у нас относится то, что делает система.

18:20

Speaker A

Например, пользователь зарегистрировался в системе, пользователь произвёл оплату, пользователь забронировал самокат. К нефункциональным требованиям перейдём.

18:29

Speaker A

Это то, как система должна выполнять свою работу. То есть это информация о качестве системы, о качестве её работы.

18:37

Speaker A

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

18:57

Speaker A

самокатов. И, соответственно, первым делом, что вы должны сделать - это задать вопросы. Причём вопросы такого характера, которые помогут вам принять архитектурные решения. К таким вопросам относятся, например, какой охват вы планируете? Это будет один город миллионник или федеральная сеть? Ответ

19:15

Speaker A

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

19:32

Speaker A

микросервисы и, скорее всего, шардирование. Итак, следующий вопрос - это требование к реальному времени. Насколько нужно часто обновлять информацию о геоданных? К примеру, если, да, нужно обновлять достаточно часто и обновлять их каждые 5 секунд, то, соответственно, в этом случае мы будем

19:48

Speaker A

использовать веб-сокеты и так далее. Если же достаточно обновлять данные каждые 30 секунд, то мы остановимся на обычных restp.

19:58

Speaker A

Теперь мы с вами перейдём к архитектуре системы. После того, как мы определили с вами цели, свойства и требования, мы переходим непосредственно к каркасу нашей системы. Архитектура описывает, как наша система связана и с чем она взаимодействует. Она определяет путь

20:14

Speaker A

данных взаимодействие также распределение нагрузки и способность справляться с ростом нагрузки. Мы с вами начнём с самого простого и будем имитировать реальный проект и постепенно его наращивать. Сейчас мы с вами поговорим про монолит. Когда сервис только запускается, никто не строит

20:33

Speaker A

какие-то сложные системы. И, соответственно, для MVP более чем достаточно использовать монолитную систему. Монолит - это единое приложение, где всё находится в единой кодовой базе. На примере нашего сервиса Аренда самокат Wшurent или Яндекс GO, мы понимаем, что пользователь выполняет

20:50

Speaker A

запрос, арендует самокат. Этот запрос уходит на эээнд, ээнд отправляет данные в базу данных, и таким образом пользователь получают арендованный самокат. Плюсы монолита - это простота загрузки и скорость. К минусам монолита можно отнести то, что это тяжело масштабировать. Также в случае

21:10

Speaker A

какого-то-либо сбоя это необходимо перезапускать целое приложение. Монолит отлично подходит на старте проекта, но когда проект начинает расти, то монолит начинает просто захлёбываться от роста нагрузки. Следующим этапом - это будет добавление балансировщика нагрузки.

21:27

Speaker A

Балансировщик нагрузки принимает запросы. Далее балансировщик нагрузки распределяет запросы между копиями ээкэнд-серверов. Из плюсов можно добавить то, что система позволяет горизонтально масштабироваться, то есть добавлять дополнительные копии бкэнд приложения. Из минусов всё также и остаётся сам монолит. В случае сбоя

21:48

Speaker A

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

22:06

Speaker A

неуправляемым и соответственно нам необходимо разделить его на микросервисы. Микросервисы представляют собой отдельные модули, которые выполняют свою бизнес-задачу. В таких приложениях, как WшH, Urent или Yandex Go, это может выглядеть таким образом. К примеру, сервис AUS или AOSice - это тот

22:24

Speaker A

сервис, который отвечает за регистрацию пользователя в системе. Userсевиice - это тот сервис, который отвечает за профили пользователей. VCles. VCK будет отвечать у нас за информацию о самокатах, соответственно, где они находятся, какой у них уровень заряда.

22:40

Speaker A

Service Rentals будет отвечать за то, когда завершилась аренда, когда она началась. Service Payments будет отвечать за все платежи. Соответственно, у нас остаётся сервис Notification, который будет отвечать за уведомления.

22:53

Speaker A

Итак, благодаря микросервисов мы добиваемся того, что каждая команда не будет мешать друг другу. То есть, например, команда Аусервера выполняет какие-то задачи, и она никоим образом не будет мешать payments сервису. И также, если будут выполняться задачи на Payment-сервисе, то это никак не будет

23:11

Speaker A

влиять на notтифиication. К примеру, в выходные количество аренд сильно возросло, и нам необходимо доработать, точнее, добавить копии к rentлсерверсу.

23:22

Speaker A

Соответственно, эта история никаким образом не повлияет на всю систему в целом. То есть мы не будем трогать остальные части нашей микросервисной архитектуры. И в этом и заключается суть микросервисного подхода. Теперь давайте поговорим про хранение данных. Для обеспечения высокой скорости, а

23:40

Speaker A

обработки запросов нам необходимо использовать гибридную архитектуру хранения. Для этого мы используем Postc SQL для хранения данных в качестве основной базы данных. Также мы используем реплики, не забываем про кэш-данные, которые храним непосредственно в Рейдисе. Также мы используем S3 для хранения медиафайлов.

24:00

Speaker A

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

24:14

Speaker A

Итак, пришла пора поговорить на тему нагрузки и масштабирования. На первых порах система работает отлично, 100, 1.000, 10.000 пользователей. Система работает превосходно, обрабатывает всё это количество пользователей. Но наступает лето, и количество пользователей возрастает. Возникает необходимость обрабатывать более 100.000 пользователей. И система начинает просто

24:35

Speaker A

задыхаться. Она не понимает, как обрабатывать все запросы. А точнее, не просто не понимает, она не справляется с тем, чтобы обработать такое количество запросов. В таком случае нам необходимо подумать о масштабировании.

24:48

Speaker A

Масштабирование бывает горизонтальное и вертикальное. В первую очередь поговорим о горизонтальном масштабировании. Горизонтальное масштабирование по факту - это усиление железа. Самый очевидный способ масштабирования - это, конечно, горизонтальное масштабирование. В данном случае мы просто берём сервер помощнее, мы увеличиваем количество ядер

25:06

Speaker A

процессора, мы используем быстрый SSD и также используем больше оперативной памяти. Плюсы этого подхода- простота, но есть и минусы. Во-первых, это дорого.

25:17

Speaker A

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

25:34

Speaker A

Вертикальное масштабирование - это означает, что мы растём вширь. Вместо того, чтобы усиливать один сервер, мы берём и добавляем несколько серверов и распределяем нагрузку между ними. Как это работает? Пользователь открывает приложение, летит запрос на сервер, соответственно, его принимает балансировщик нагрузки, например, далее

25:54

Speaker A

балансировщик нагрузки выбирает тот сервер, который наименее загружен, и направляет туда запрос. Если же пользователь становится ещё больше, то мы просто добавляем ещё какое-то количество серверов в пул. Итак, о'кей, мы количество ээкнд-серверов расширили.

26:09

Speaker A

Но что у нас происходит с базой данных? База данных у нас так и остаётся узким местом, потому что все запросы идут в одну точку. Решением будет являться добавление репликаций, то есть мы будем разделять базу данных на чтение и на

26:24

Speaker A

запись. То есть у нас будет главная база данных, которая будет отвечать за запись данных. К ней будут обращаться в случае, когда пользователь арендует самокат, завершает аренду самокатом или, например, оплачивает аренду самоката.

26:38

Speaker A

Копии будут обслуживать чтение, например, посмотреть историю поездок. Таким образом, мы разгружаем базу данных. И в случае, если пользователю нужно посмотреть историю поездок, то обращение будет идти к реплике. А в случае, если пользователю необходимо оплатить аренду самоката, то, соответственно, будет идти запись в

26:56

Speaker A

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

27:12

Speaker A

И, к примеру, Москва будет у нас находиться в кластере 1, Санкт-Петербург будет находиться в кластере 2, а Казань будет находиться в кластере 3. Каждая база данных обслуживает только своих пользователей. И, соответственно, в случае, если в Москве находится пиковая

27:27

Speaker A

нагрузка, то это никак не влияет на Санкт-Петербург и Казань. Самое большая сложность в данном случае - это маршрутизация, но её легко решить при помощи шардин ID, например, C ID, который будет определять местоположение нашего пользователя и направлять в нужный шар.

27:47

Speaker A

Теперь поговорим про проектирование API или просто app. IPI, по сути, - это язык. язык, по которому взаимодействует сервер и клиент. И каждое действие пользователя, начиная от входа в приложение до начала аренды самокатов, это всё происходит при помощи взаимодействия сервера и клиента. И всё

28:07

Speaker A

это происходит при помощи IP. В данном случае фн у нас не знает ничего о том, что происходит внутри бэкэнда. То есть он не знает о нашей внутренней архитектуре, о наличии микросервисов, о базах данных и КШ. Пользователь выполняет какое-то действие. Фронтнд

28:24

Speaker A

делает запрос к бэкэнду и просит: "Дай мне список самокатов на основе моих координатов". И ээкэнд обрабатывает этот запрос и в итоге говорит: "На, держи".

28:35

Speaker A

Всё, что делает пользователь и взаимодействует с приложением, происходит через IP. Самый распространённый способ общения с сервером - это REST IPI. Он основан на HTTP протоколе и интуитивно понятен.

28:48

Speaker A

Rest довольно легко читается. тестируется. И именно поэтому он практически по стандарту, по де-факто он используется для взаимодействия с мобильным приложением. А должен быть интуитивно понятным. И, соответственно, для этого мы используем максимально простые действия, например, как HTTP глаголы. Такие HTTP глаголы, как get для

29:11

Speaker A

получения ресурса, пост для создания ресурса, т или патч для обновления ресурса и delete для удаления ресурса.

29:19

Speaker A

Также в REST IPI важна структура, то есть все запросы будут строиться, например, в множественном числе. К примеру get/users get/rentals.

29:31

Speaker A

Также в Rest API мы используем версионирование. Оно обязательно в случае, если у нас старое приложение и новые какие-то доработки ломают его, то в данном случае нам необходимо использовать версионирование. Плюс его заключается в том, что старое приложение будет работать на одной версии, э, IPI,

29:50

Speaker A

а новое приложение будет работать на новой версии IPI. К таким примерам можно отнести v1/users, V2/users.

30:00

Speaker A

Соответственно, старое приложение работает с версией V1, а новое приложение работает с версией V2. Также важно учитывать и домпотентность. В случае, если пользователь совершит один и тот же запрос несколько раз, то результат не должен измениться. Итак, представьте такую ситуацию, что

30:16

Speaker A

пользователь нажимает на кнопку "Начать аренду". И в это время у нас плохое соединение мобильного интернета. И дважды ушёл запрос на создание поездки.

30:25

Speaker A

В этом случае у нас может создаться две поездки и, соответственно, дважды спишутся деньги. Для того, чтобы нам такую историю предотвратить, нам необходимо использовать идомпотентность.

30:35

Speaker A

Идопатентный Апи защищает от таких историй и, соответственно, на стороне сервера проверяет идопатентный ключ и не позволяет создавать дублированные поездки. А это довольно-таки важно в случае, когда у нас нестабильный мобильный интернет. Также REST IPI должен быть безопасным. То есть у нас

30:53

Speaker A

API является основной точкой входа в систему. И также каждый REST API должен сопровождаться токеном авторизации. На стороне AP Gateway должна производиться проверка токена авторизации. И Gateway должен подтверждать, что это действительно доверенный запрос, и он может продолжать выполнять свою работу

31:12

Speaker A

дальше. Также App Gateway должен выполнять проверку на то, что все запросы идут по https. И такие чувствительные данные, как платёжные токены, они должны шифроваться. Такой подход защищает не только пользователей, но и защищает сам бизнес. Итак, мы увидели, что взаимодействие с

31:29

Speaker A

приложением, оно довольно-таки простое, интуитивно понятное, но под капотом у нас скрывается довольно сложная архитектура. То, когда мы начинаем с нуля, с монолита и заканчиваем работы с микросервисами, репликами и шардингом.

31:43

Speaker A

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

32:00

Speaker A

Подписывайтесь на мой канал. Надеюсь то, что информация, которую я вам сегодня рассказала, была максимально полезной.

32:07

Speaker A

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

32:28

Speaker A

нагрузкой, может всплыть целый ворог проблем. Например, среднее время ответа 20 миссекунд, но иногда секунды, и пользователи жалуются, что ничего не работает и всё глючит. Рекламная акция дала всего + 5% посетителей, а продакшн лёг. попытались ускорить систему, а в

32:49

Speaker A

итоге замедлили её, да ещё и поймали плавающие баги. Про эти эффекты нужно думать уже на стадии проектирования, в том числе когда вы проектируете систему на собеседовании по систем-дизайну. В этой главе мы последовательно разберём следующие проблемы: letнси, задержку и

33:07

Speaker A

хвост задержек. Почему среднее время ответа в системе маленькое, а пользователи всё равно страдают? пропускная способность FRP и очереди.

33:18

Speaker A

Как посчитать, какую нагрузку ваша система реально выдержит? Шардирование стратегии, динамическое распределение шардов, кроссшард и миграции без простоя. Распределённые транзакции между сервисами Тупиc, TCC, саги и как не утонуть в примерно согласованных деньгах. Многослойное кэширование и когерентность. Что делать, когда у вас

33:44

Speaker A

CDN, дис, локальный кэш и фичефлаги поверх релизов? Трейдофы и оптимизации, где реально стоит платить за сложность, а где можно просто добавить побольше железа и жить спокойно. Задача этой главы - дать тебе язык и инструменты, чтобы обсуждать архитектуру не в стиле

34:05

Speaker A

"Нормально делай, нормально будет", а в терминах задержек, стоимости и консистентности. Начнём с базовой механики производительности Latency, хвост задержек, и очередей. Поверх неё нарастим шардирование, распределённые транзакции и продвинутое кэширование. Те инструменты, которыми ты будешь спасать сервис, когда он будет тонуть под

34:28

Speaker A

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

34:47

Speaker A

Представь себе, что ты открыл приложение, нажал на какую-то кнопку, и оно думает. Первый раз ты думаешь: "Ладно, тратил я время и на более бесполезные вещи. Подожду. Второй раз думаешь, раздражает. На третий раз просто закрываешь приложение и уходишь к

35:03

Speaker A

конкуренту. Разработчики при этом читают твои жалобы, идут смотреть метрики и видят, что среднее время отклика в системе равно 200 мкунд. Всё отлично летает. Но пользователям безразлична средняя температура по больнице. Их волнует одно: уложился ли их конкретный запрос в нужные миллисекунды или прошло

35:27

Speaker A

несколько секунд. Таким образом, медленно работающие сервисы и приложения приводят нас к потере клиентов, а значит, денег. Это важная проблема, её ни в коем случае нельзя игнорировать и в работе, и на собеседовании, где ты должен показать, что вы не просто

35:45

Speaker A

какие-то абстрактные задержки, секунды, шарды обсуждаете, но ты понимаешь, зачем это делается, чтобы приносить бизнесу деньги и предостерегать, уберечь его от их потерь. Чтобы понять, что с этим делать, для начала определимся с базовой терминологией. У нас есть три главных

36:04

Speaker A

понятия. это latenнcy, задержка, пропускная способность throughput и уровень параллелизма concurrency. LetнCY - это сколько времени наш запрос живёт внутри системы, от момента, когда мы в неё зашли до момента, когда мы из неё вышли, например, 200 мкунд или 2

36:23

Speaker A

секунды. Пропускная способность through. Сколько запросов в секунду мы можем стабильно завершать? Например, 1.000 RPS. уровень параллелизма concurrenнcy.

36:34

Speaker A

Сколько запросов наша система может обрабатывать параллельно? Какие-то стоят в очереди, какие-то уже обрабатываются. Всё это висящие запросы. Представим какую-нибудь пятёрочку рядом с домом и применим эти термины к ней. Latenнcy в данном случае - это время, сколько клиент проводит в магазине от входа до

36:54

Speaker A

выхода. Т- сколько людей в минуту проходит через наши кассы. Конкарен. Сколько людей сейчас в очереди?

37:03

Speaker A

Очевидно, что все эти понятия взаимосвязаны. То есть, если перед вами уже есть очередь, то время ожидания будет больше. Ровно как и если бы FRP был выше, то очередь накапливалась бы меньше. Эта закономерность описывается законом.

37:20

Speaker A

Вот формула. Давай разберём на примере. Система стабильно держит 1.000 RPS и каждый момент внутри 3.000 запросов.

37:28

Speaker A

Тогда letнсиc будет равняться 3 секундам. Задержка равна уровень параллелизма разделить на пропускную способность. То есть задержка равно 3.000 / 1.000. Получаем 3 секунды.

37:41

Speaker A

Теперь добавим поток входящих запросов. Входящий поток 1.00 RPS. Система успевает стабильно обрабатывать только 1.000 RPS. Разница 500 RPS превращается в рост очереди. каждую секунду внутри становится на 500 висящих запросов больше. Конкарен растёт и через формулу задержка равно уровень параллелизма

38:04

Speaker A

разделить на пропускная способность, автоматически растёт и задержка. Если система в таком режиме будет работать довольно долго, то получаем печальную ситуацию. Очередь растёт без верхней границы. ТНСИ растёт и стремится к бесконечности. Пользователь видит ситуацию: "Всё умерло". ничего не работает. Хотя железо по факту работает,

38:28

Speaker A

система по факту жива, но к обработке запроса пользователя она приступит очень нескоро. Таким образом, если поток реальных запросов хотя бы на несколько секунд превышает реальный фруpпут, то очередь будет расти и latenнcy будет расти. Вдобавок система может начать деградировать под такой нагрузкой, и всё

38:49

Speaker A

станет ещё хуже. Сейчас ты можешь спросить от меня здесь, что конкретно требуется? Ну, в смысле, зачем мне нужна эта информация? На практике это понимание помогает принимать решения. То есть ты видишь, что в системе сейчас 10.000 запросов, пут у тебя 2.000 RPS.

39:10

Speaker A

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

39:31

Speaker A

Это rate liмитинг, backп pressure или очереди. На собеседовании так и нужно рассуждать. Не давайте просто увеличим количество серверов и всё будет хорошо.

39:43

Speaker A

А при таком количестве реальных запросов и неизменном put в очередь неизбежно будет расти и будет растин.

39:54

Speaker A

Чтобы этого избежать, нам нужно изменить баланс concurrenнcy иpot. Значит ли это, что мы можем просто измерить latenнcy и пойти домой? Да, к сожалению, здесь ещё сценария на 40 страниц, поэтому, видимо, нет, не можем.

40:13

Speaker A

Мы только в самом начале разберём такой пример. У нас есть 100 запросов. 90 обрабатываются за 100 мкунд, 10 за 5 секунд. В среднем у нас 590 мскунд. На бумаге это выглядит терпимо. По факту 90 человек получают быстрый ответ и думают:

40:33

Speaker A

"Ну, нормально работает". А 10 человек видят загрузку на 5 секунд и идут писать негативные отзывы. Бизнесу важны не абстрактные 590 мскунд в среднем, а какая доля пользователей попадает в негативный опыт и насколько плох этот опыт по времени. Для этого вводят

40:52

Speaker A

перцентили. Перцентиль в данном случае - это время, быстрее которого обслуживается определённый процент запросов. Например, перцентиль 50.

41:04

Speaker A

Половина запросов быстрее этого времени. По сути, медиана. При перцентиле 95% запросов быстрее этого времени. Ну и 99 запросов быстрее. Представим, что для нашего продакшена метрики следующие. Как нам это читать и что это значит?

41:25

Speaker A

Половина запросов улетает за 150 мисекунд. Великолепно. Ещё 45 укладываются в 400 мскунд. Терпимо. Последний 1% сидит по 2 секунды. Это те самые недовольные пользователи из нашего примера выше. Тут возникает новый термин Tailatency. Это тот самый небольшой процент очень медленных запросов. Да,

41:48

Speaker A

кстати, для правильного проговаривания всех англицизмов я специально ездил учиться в Гарвард на 2 месяца. Так что напишите в комментариях, если вам понравился мой English accent. В реальной жизни и на собеседованиях разговор про производительность всегда должен идти в терминах девяносто пятый и

42:08

Speaker A

девяносто девятый персентиль, а не, ну, в среднем у нас всё норм. При этом в распределённых системах хвосту свойственно удлиняться. Почему так происходит? В Монолите запрос на создание заказа может состоять из четырёх звеньев: веб-сервер, поход в базу, поход в кэш и немного логики

42:27

Speaker A

внутри самого монолита. В микросервисной же архитектуре в цепочке становится гораздо больше звеньев. Веб-сервер, сервис А, сервис B, сервис C. При этом каждый из сервисо входит в свою базу и кэш. Теперь представим, что у каждого звена пятидесятый перцентиль- 50 мскунд,

42:47

Speaker A

а девяносто девятый- 200 мсекунд. Большинство запросов будут быстрыми, но вероятность попадания запросов в хвост задержек растёт по теории вероятности с увеличением количества звеньев. В итоге по отдельности все сервисы нормальные.

43:02

Speaker A

Девяносто девятый персентиль 200 миссекунд. Нормал. Но девяносто девятый персентиль по нашему запросу может достигать 2 секунд. Если мы поймаем хвост задержек в каждом из звеньев. Ты или твой коллега, который ещё не смотрел этот потрясающий гайд, могут сказать: "Давайте просто добавим серверов, оно

43:24

Speaker A

само как-то и починится". Далее мы как раз будем обсуждать, почему добавлением железа проблему не решить и как нам уменьшить хвост задержки и не дать ему убить систему. Но откуда берутся эти хвосты? Ведь они, по определению, возникают лишь иногда, и причина

43:42

Speaker A

плавающая, и вряд ли в коде, не так ли? На то есть три группы причин. Это аппаратные, сетевые и программные.

43:50

Speaker A

Аппаратные - это когда, например, throtling на диске из-за лимита чтения записи или Thermal Throtling. На процессоре. Живой пример одного из авторов курса. Его продукт был расположен на московских ЦОДАх. Как-то раз выдался особо жаркий день. И хотя не с их стороны, ни с чей-либо никаких

44:13

Speaker A

релизов и изменений не было. Система в тот день сильно деградировала, мало что вообще грузилось, а запросы падали с 502 504 ошибкой. Сетевые - это, например, congestion из-за соседнего сервера или долгие DNS-запросы. Программных причин вообще бывает миллион. Это очереди,

44:35

Speaker A

конкуренция за ресурсы, оптимистичные пессимистичные блокировки. Эффект noisy Neighbor, когда другой сервис на той же ноде начинает потреблять выделенные ресурсы и вам их не хватает, бывает на виртуалках или в облаках. Сборка мусора, ротация или ретенtion логов, перезапуск процессов, синкбазы. Для хвостов не

44:59

Speaker A

нужно, чтобы что-то было сломано. достаточно лишь маленькой вероятности плохого сценария, которое при большой нагрузке и большом трафике обязательно случится. Одиночный хвост конечно сам по себе неприятен, но систему не убивает. Гораздо хуже, когда система пытается умно на него реагировать. Как это может выглядеть?

45:23

Speaker A

Наш запрос поймал хвост. Клиент, мобильное приложение или фронтEN сделал повторный запрос. Ашлюз тоже умеет ретраить, ну, для надёжности. И в нашем сервисе тоже прописано ретраи с тайм-аутом. В результате вместо одного застрявшего запроса мы можем получить h27, если на каждом из наших слоёв будет

45:48

Speaker A

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

46:08

Speaker A

бизнес-трафик не сильно вырос. Это не значит, что мы убираем ретраи. Они сами по себе нужны, но за ними нужно следить, ограничивать количество попыток и на каждом слое, и в цепочке в целом. То есть не while true. Бесконечно отправляем запросы. Привязывать ко

46:26

Speaker A

времени. Экспоненциальный бэкоф. стерм по-простому, когда время между ретраями увеличивается через секунду, через 3, через 10. Выделить ответственную часть системы за ретра. Либо клиент, либой, либо сервис. Короче, без UML диаграммы здесь не обойтись. Иначе надёжность через ретраи легко превращается в

46:51

Speaker A

механизм добивания и без того больной системы. Итак, что же делать, если с хвостами мы всё-таки столкнулись? Все способы борьбы с хвостами делятся, по сути, на две группы. Уменьшить хвост, сделать так, чтобы медленных запросов реально стало меньше. Спрятать или

47:09

Speaker A

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

47:26

Speaker A

собой весь сервис. Начнём с уменьшения хвостов. И первый способ hatched requests. Идея hatched запросов в том, чтобы не бесконечно ждать, а вдруг повезёт и отработает, а при возникновении повисшего запроса дать ему шанс на другой ноде. Схема такая.

47:45

Speaker A

Сначала измеряем latency и строим распределение. Выбираем порог, например, Сентиль девяносто пяты. Когда приходит запрос, шлём его на обычную реплику.

47:55

Speaker A

Если он не успел завершиться за девяносто пятый перцентиль, отправляем вторую копию на другую реплику. Берём первый успешный ответ, второй считаем лишним и отменяем, если это возможно.

48:07

Speaker A

Число параллельных копий ограничиваем. Обычно две, иногда три, но не по всем инстанцам. Важно заметить, что такую технику можно применять только на идемпотентных операциях. Если, например, мы два раза спишем денежку, то пользователь будет не очень доволен, как и бизнес. Здесь мы платим

48:27

Speaker A

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

48:40

Speaker A

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

48:50

Speaker A

Поставить перед тяжёлым ресурсом очередь. Вместо того, чтобы попытаться обслужить все запросы сразу, принимаем задачи и складываем их в очередь.

49:00

Speaker A

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

49:11

Speaker A

Однако рискуем получить дополнительную latenнcy и рискуем получить head of line blocking, если будем неаккуратны в выборе размера очередей и политики обработки. Также есть Qbased leveling, который выравнивает нагрузку через очередь. Подход, связанные запросы используют несколько очередей, чтобы быстрее найти свободного

49:38

Speaker A

исполнителя, но без лишних дублей работы. По шагам выглядит так. Клиент шлёт запрос на сервер А. Через маленькую паузу порядка одного-двух roundт time, то есть RTT 5-10 мсекунд копию на сервер B. Оба запроса несут общий request ID.

50:01

Speaker A

Когда один сервер берёт запрос в работу, он помечает request id как в работе, через быстрый стор внутренний протокол и шлёт касel для копии. Если на второй ноде запрос всё ещё стоит в очереди, его просто выкидывают или понижают приоритет. Как и в этом подходе, когда

50:20

Speaker A

мы отталкиваемся от загруженности очереди сервиса, есть подход, который распределяет загрузку в зависимости от скорости ответа ноды. Latency Aware lot balancing. Обычный раундро считает, что все носиме одинаковы, но на практике часть нот может быть загружена или, например, попасть на более медленный

50:46

Speaker A

диск. Latency Aware Lot Balancing же смотрит на историческую задержку по нодам и шлёт задачи тем нодам, у которых lланси выше. Таким образом даёт отдохнуть уставшим или деградировавшим нодам. Из минусов это, конечно, усложняет работу балансировщика. Есть ещё одна техника request coacing. В ней

51:09

Speaker A

первый запрос реально идёт вниз. Остальные, которые пришли с тем же ключом, мы временно подвешиваем. Когда первый вернулся, раздаём его результат всем ожидающим. Мы уменьшаем конкарен на нижнем уровне, становится меньше нагрузка на БД, внешний сервис и ниже шанс, что девяносто девятый перцентиль

51:30

Speaker A

превратится в секунды. Также можно размазать нагрузку по времени, это называется background gittering. Добавляем случайную компоненту в расписание. Вместо 1.сячи задач в конкретное время получаем 1.000 задач, размазанных по минуте. Если же какие-то процессы запускаются не только по ночам, а в течение всего времени, да ещё и не

51:51

Speaker A

на одной машине, то может помочь обратный подход synchronize disruption. Мы можем запускать эти процессы везде в один момент. Тогда только запросы, пришедшие в этот момент, подвиснут, а в остальное время хвостов не будет. То есть система не всё время

52:11

Speaker A

подтормаживает, а потратила пару секунд, чтобы потормозить, и дальше снова работает хорошо. Backк pressure - это ограничение входного потока под пропускную способность ресурса. Идея в том, что система должна честно сказать: "Я больше не вывожу". И не принимать больше ничего на вход, вместо того,

52:31

Speaker A

чтобы раздувать очереди и увеличивать латнеси. Как это можно организовать? Устанавливаем лимиты на одновременные запросы к BD, редису, внешним или очередям. Ограничиваем размер очередей перед воркерами. При превышении лимита есть варианты. Мы либо быстро отдаём 429 или 503, или отправляем сообщение в Dead

52:56

Speaker A

letter Q, или просим клиентаретраить позже с Backof плюс gitter. Все эти умные слова и англицизмы - это просто паттерны для уменьшения хвоста. Это нормально, что ты не можешь сразу их запомнить и осознать, в конце концов, кто из нас не читал банду четырёх и не

53:19

Speaker A

офигевал от того, сколько там всего есть и как это вообще применять, а потом использовал буквально два-три паттерна в повседневной жизни. На всякий случай мы выведем всё, что мы перечислили здесь на экран. Пока можно это не зубрить и не

53:34

Speaker A

запоминать, вернуться к этому позже. Главное осознать принципы и сами идеи борьбы с этими хвостами. Теперь пройдёмся по подходам маскировки хвоста.

53:47

Speaker A

Паттерн Circuit Breaker похож на Back Pressure, но работает не с мощностью, а со здоровьем удалённого ресурса.

53:55

Speaker A

Механизм такой: мы следим за долей ошибок и тайм-аутов при обращениях к BD и внешнему API. Если процент ошибок превышает лимит, то мы размыкаем цепь сразу, возвращаем запросы с ошибкой или быстрым фолбэком. Мы вообще перестаём ходить в зависимость, которая явно

54:16

Speaker A

нездорова. Пока брейкер открыт, мы периодически делаем пробные запросы. Если они начинают успешно проходить, мы закрываем брекер и постепенно возвращаем трафик. То есть вместо того, чтобы каждый запрос висел до тайм-аута, мы быстро возвращаем контролируемую ошибку или быстрый ответ. Таким образом спасаем

54:36

Speaker A

остальную систему и наш UX. Есть ещё один подход. Deadline propagation. Мы считаем какой-то приемлемый порог выполнения запроса и пропихиваем его в заголовке, например, на уровне балансера. Так хвостовые запросы не зависают бесконечно, а система тратит меньше ресурсов на заведомо проигрышные

54:57

Speaker A

попытки. Любимый многими подход good enough. Как можно догадаться из названия, лучше сделать быстро как-нибудь, чем идеально, но долго.

55:08

Speaker A

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

55:31

Speaker A

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

55:50

Speaker A

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

56:09

Speaker A

системах необходимо делать distributed tracing, то есть связывать логи разных компонентов по идентификатору, ну, например, по идентификатору запроса. Это помогает увидеть, какое звено в цепочке даёт хвост, и отличить хвост базы данных от хвоста сети или хвоста очереди. Про алерты, конечно, тоже не стоит забывать,

56:32

Speaker A

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

56:54

Speaker A

которые хочется донести. Хвосты - это не баги, это естественное поведение сложных систем. Задача команды разработки не сделать хвосты нулевыми, а мониторить и контролировать их, предотвращая поломку пользовательского опыта.

57:15

Speaker A

Итак, мы разобрали, что по закону Литла, если мы увеличим пропускную способность, то задержка уменьшится. Если мы хотим удержать задержку на приемлемом уровне при повышении нагрузки, нам нужно либо увеличивать пропускную способность, либо ограничивать конкурентность, о чём мы также немного поговорили ранее. Как

57:36

Speaker A

увеличить пропускную способность? Первое, что приходит на ум, давайте просто купим ещё железо, и всё будет зашибись. Но увеличение количества серверов может как ускорить нас, так и, наоборот, замедлить. Поэтому, прежде чем скоропалительно делать такое решение, давайте обратимся к законам

57:55

Speaker A

масштабирования пропускной способности. Всего их три: закон Амдаля, закон Густавна и Universal Scalability Law или же Закон универсальной масштабируемости.

58:08

Speaker A

Кажется логичным. Нужна больше пропускная способность. Давайте добавим больше серверов, воркеров или реплик. Законом Далее говорит нам о том, что ускорение системы ограничено той частью её, которую нельзя распараллелить.

58:22

Speaker A

Представим какой-то запрос. 70% времени тратится на параллещуюся часть. можно растащить по серверам или воркерам, а 30% времени строго последовательная часть. Один мастер, один log, а один общий ресурс. Формулам дали на ваших экранах. В ней пи. Доля параллещейся части в нашем примере равна 0,7. То

58:45

Speaker A

есть, согласно этой формуле, хоть миллион серверов ты добавь, но если доля непараллещейся работы 30%, то максимально ты ускоришься в три и три раза примерно. Теперь Густав. Дело в том, что запрос бизнеса не всегда звучит как: "Нам нужно сделать то же самое,

59:05

Speaker A

только быстрее". Часто запрос звучит по-другому. У нас есть фиксированное время, например, 200 мкунд или 1 час ночной джабы. Сколько мы можем успеть сделать работы за это время, если добавим ресурсов? Тут уже нам пригождается закон Густовсона. Как из закона Мдаля, мы не получаем линейного

59:25

Speaker A

ускорения от добавления новых серверов, но формула уже другая. Формула Густовсона для ускорения при n, в нашем случае восьми узлах у вас на экранах.

59:36

Speaker A

Альфа здесь - это доля непараллещейся части, в данном случае 10%. Идеал, как мы понимаем, X8, но в реальности мы можем ускориться только в 7,3 раза. 10% непараллещейся работы остаются узким горлышком. В терминах Густовсона мы не уменьшаем задержку отчёта, мы

59:55

Speaker A

увеличиваем объём работы, который можем сделать за то же самое время. Амдали Густовсон говорят нам, какая теоретическая польза от добавления ресурсов. В реальности же при добавлении ресурсов мы начинаем платить дополнительные издержки, например, за конкуренцию, за общие ресурсы или за

60:16

Speaker A

согласование состояний между репликами или слоями системы. Это описывает закон универсальной масштабируемости. Формулу вы можете увидеть на своих экранах. К сожалению, я слишком тупой, чтобы это прочитать вслух. Здесь S от - это SpeedU. Насколько же вырастет пропускная способность или объём работы в единицу

60:36

Speaker A

времени при n узлах по сравнению с одним узлом? N - число узлов. Сигма - накладные ресурсы на конкуренцию за общие ресурсы. Каппа. Накладные расходы на согласованность между репликами.

60:50

Speaker A

Какой вывод можно сделать из этого закона и примера кривой? Здесь можно увидеть, откуда берётся реальный эффект.

60:58

Speaker A

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

61:18

Speaker A

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

61:35

Speaker A

Затем мы добавляем реплики для чтения. чтобы снять нагрузку с мастера и кормить отчёты или аналитику. Кажется, пропускная способность растёт. Фронтнд и аслой масштабируется. Чтение уезжает на реплики. Но возникает ряд проблем. Все операции по деньгам, списание, возврат, удержание всё равно упираются в мастер.

61:58

Speaker A

Транзакции rowock. Проверка инвариантов вокруг балансов не дают распараллелить этот кусок. По мере роста числа приложений, которые бьются в ту же самую базу данных, растёт contention. По горячим строкам и индексам мы наращиваем количество приложений и реплик, но Сигма и Капа в формуле USL растут быстрее, чем

62:23

Speaker A

пропускная способность по деньгам. Рост нагрузок приводит к росту lock contention и стоимости репликации. В какой-то момент добавление новых сервисов или реплик перестаёт помогать.

62:37

Speaker A

Пропускная способность по критичным операциям платежей почти не растёт, а хвост задержки чекаута начинает ухудшаться. Что мы можем с этим поделать? Тут есть две основные практики. Первое - это разделение нагрузок и данных, изоляция ход ресурсов. Об этом мы чуть позже

62:55

Speaker A

поговорим. А о второй я уже упомянул. Предлагаю вам в комментариях поспорить, какой из законов нам может здесь помочь и как.

63:09

Speaker A

Представим такую ситуацию. У нас есть большая таблица Orders. В ней уже десятки и сотни миллионов строк. Индексы раздулись. Вакуум занимает много времени и никогда не заканчивается. Бэкапы занимают всю ночь. Секска по этой таблице начинает занимать секунды. Сама таблица весит уже терабайты. Тем

63:32

Speaker A

временем мы хотим, чтобы данные за последние дни, недели, то есть горячие данные, обрабатывались быстро, ретенш старых данных проходил быстро, отчёты за год не перегружали базу, ну и бэкап был быстрым. Что мы делаем? Профилируем и переписываем запросы. Работаем над

63:51

Speaker A

индексами, нормализуем и денормализуем данные там, где это уместно. Выжимаем вертикальное масштабирование. И только когда всё это уже не спасает, вводим партиционирование на одном кластере. Что такое партенирование? Это когда одна логическая таблица разбита на несколько физических кусков, но при этом всё это

64:15

Speaker A

живёт в одном инстансе базы данных. и при этом по возможности прозрачно для приложения. При этом мы можем резать таблицу вертикально по столбцам и горизонтально по строкам. Шардирование в принципе то же самое, но живёт всё в разных инстанцах. На всякий случай хочу

64:34

Speaker A

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

64:43

Speaker A

Например, тот самый Мартин Клепман использует партиционирование как общий термин для разрезания данных на часть, а шар или партия просто разные названия этих кусков данных в разных системах.

64:59

Speaker A

Зачем я это уточняю? Просто если какой-то душный лид, синьор начинает уточнять у тебя термин или гонять тебя в глубину насобесие, не нужно жёстко стоять на своём и говорить: "Нет, вот только так и по-другому никак". В IT, безусловно, есть термины,

65:17

Speaker A

которые можно озвучивать только там в каноничном академическом определении, а есть термины вот такие, которые разные люди понимают по-разному. Поэтому лучше в каких-то моментах понять, что там твой техлит фанат именно вот этой статьи и сказать: "Ладно, хорошо, типа, пускай не

65:35

Speaker A

будем здесь зарубаться". Но зачем вообще нужны шарды, когда есть партиции? Шардирование пригодится, когда необходимо увеличить пропускную способность записи. Например, один HDD даёт 200 Мб в секунду, а SSD больше.

65:49

Speaker A

Распределить CPU нагрузку. Геораспределение. Например, пользователя из Европы отправляем на кластер, находящийся в Европе, когда таблицы или индексы физически не помещаются на один сервер, там в один диск или скоро перестанут помещаться. При этом почти всегда шардирование идёт в паре с

66:08

Speaker A

репликацией. Каждый шарт имеет свои реплики, иначе падение одной машины повлечёт смерть куска данных или сервиса. Шардирование, как и партионирование, сильно усложняет систему. Поэтому важно понимать, что это не то, что нужно закладывать в систему с самого начала, и лучше обходиться без этого, пока это

66:29

Speaker A

возможно. Например, GitHub долгое время жил на монолитной базе и выдерживал 950.000 транзакций в секунду. Прежде чем двигаться дальше, определимся с базовой терминологией. Что такое shart key, hot key, перекос распределения и маршрутизация? Шар key, то есть ключ шардирования - это ответ на вопрос, по

66:53

Speaker A

какому признаку мы разбиваем данные и на какой шарт отправится наш запрос. Например, user ID, created или region.

67:03

Speaker A

Выбор правильного ключа шардирования крайне важен, потому что от него будет зависеть баланс нагрузки, цена миграции и сложность запросов. Что делает ключ шардирования хорошим? Он более-менее равномерно размазывает нагрузку и объём данных. И типичные бизнес-запросы выполняются в пределах одного шарда, ну

67:26

Speaker A

или на малом количестве шардов. Хотки или горячий ключ - это ключ, который генерирует несоразмерно большой трафик по сравнению с остальными. Например, топовый продавец, по которому постоянно смотрят отзывы и проверяют его товары или какой-то популярный товар, лабубу, что там популярно у молодёжи, я я не

67:48

Speaker A

знаю. Или видео в трендах. Даже если мы правильно выбрали ключ шардирования, то один такой горячий ключ может превратить целый шарт в батлck или бутылочное горлышко. Горячий ключ - одна из причин перекоса распределения. Так как данные у нас теперь живут на разных серверах,

68:09

Speaker A

логичный вопрос: кто и как поймёт, куда же отправлять наш SQL-запрос? Есть три варианта: роутинг в приложении, прокси и координатор. Роутинг в приложении подразумевает, что вся логика лежит в коде и приложение знает несколько ДСН.

68:27

Speaker A

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

68:51

Speaker A

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

69:13

Speaker A

шарды трогать, строит распределённый план, умеет работать с транзакциями. Из примеров это, например, цитус для постгрес или vitess поверх MySQL. В этой главе, когда я говорю слой маршрутизации, я имею в виду не конкретный продукт, а сам принцип, что клиент знает один вход, а куда конкретно

69:34

Speaker A

пойдут запросы, решает отдельный слой, будь то роутер со своей логикой или полновесный координатор типа Цитус.

69:42

Speaker A

Теперь поговорим о ребалансировании. Это важно, потому что оно отвечает на вопрос, как вернуть здоровое распределение данных и нагрузки по кластерам, не роняя прот. Есть несколько причин, по которым может понадобиться ребалансирование. Неравномерный рост данных. Например, один шарт разросся до

70:02

Speaker A

терабайта, остальные по 100 Гб. Горячие категории. Например, один шарт получает 80-90% RPS. Рост кластера. Добавили новые шарды. Их нужно заполнить частью существующих данных. Сжатие кластера.

70:17

Speaker A

Убрали железо. Хотим сократить расходы. Смена ключа шардирования. резали по User ID, поняли, что правильное по seller ID или Tenant ID. Схема ребалансинга обычно состоит из трёх этапов. Первое - массовая переливка данных. Синхронизация изменений. Пока идёт массовая переливка данных, фиксируем все новые изменения и

70:40

Speaker A

доносим их до нового шарда. Переключение маршрутизации. Переводим чтение запись на новую схему размещения, минимизируя окно гонок. Тут я решил не останавливаться на разборе конкретных схем. Но если у тебя есть запрос, что вот надо именно на эту тему отдельный

70:59

Speaker A

видос, пожалуйста, напиши в комментариях или лайкни коммент, который это просит. Если прямо много желающих, мы обязательно снимем. Также важно, как бы хорошо мы не порезали данные, нам всё равно придётся столкнуться с операциями, затрагивающие данные с нескольких шардов или даже со всех одновременно. Такие

71:20

Speaker A

операции называются crossshar операциями. Вот некоторые из них cross, shart join. Например, на странице заказа нам требуются данные и продавца, и заказа, и товара. Cross shared aggregation, когда нам нужно посчитать оборот продавца за неделю, а его заказы уже нарезаны по user ID или по регионам.

71:45

Speaker A

Cross Shared Search, когда мы ищем товар по атрибутам, цвет, бренд, цена, размер, а они размазаны по шардированным индексам. Перед следующей частью давай немного закрепим материал и разомнёмся.

72:00

Speaker A

Представь, что мы с тобой наедине, you know, и у нас system design интервью, и я тебе задаю три следующих вопроса.

72:08

Speaker A

Только не подглядывай в комменты, там уже, скорее всего, есть правильный ответ. Чем шардирование отличается от партеционирования? Когда стоит шардировать, а когда лучше попробовать репликацию или кэширование? Как ты выбираешь ключ шардирования? Кстати, если с третьим вопросом у тебя возникли

72:26

Speaker A

затруднения и ты не можешь дать однозначный ответ, заглядывай по ссылке в описании на бусте там в приватной части видео только для участников ОМ, как правильно выбирать ключ шардирования и как решать, какой ключ куда пойдёт.

72:45

Speaker A

Допустим, мы распределили данные по шардам, логику по сервисам, но бизнес-процессы у нас никуда не делись.

72:51

Speaker A

Деньги должны списываться один раз, товары должны резервироваться, заказы создаваться. И всё это происходит через разные базы и сервисы. И вот главный вопрос: как нам выполнить многосервисную операцию так, чтобы сбой в её середине не привёл нас к неконсистентному состоянию системы? AST внутри одной базы

73:13

Speaker A

решает эту проблему одной транзакцией, но в распределённой системе у нас такого инструмента нету. У каждого сервиса своя разная база. Ещё сервис может ребутнуться или отвалиться. Так и сеть ещё добавляет новых проблем. Дальше мы рассмотрим четыре варианта, как решить

73:33

Speaker A

эту проблему. Только не смейтесь. Two PC, free PC, TCC. И вы угадали сага. Начнём сту PC to Face Commit. Это протокол распределённой транзакции между хранилищами. Есть координатор и несколько участников нот базы или шардов. На уровне протокола у нас две

74:00

Speaker A

фазы. Координатор кластера говорит всем участникам: "Выполните свою часть". Вторая фаза фиксации. когда координатор получил ОК от всех участников. Если все готовы, то он рассылает commit prepared на каждую ноду. Если кто-то не смог подготовиться, то рассылает rollback prepared на каждую

74:22

Speaker A

ноду. До тех пор, пока координатор не примет решение, каждая нода заморожена в состоянии подготовлена, но не закомичена. У PCC есть неприятные свойства. Во-первых, если координатор умер в неприятный момент, то часть транзакции зависает в состоянии prepaired. Во-вторых, prepair держит

74:42

Speaker A

блокировки, пока координатор думает, а значит, растут очереди и хвосты задержек. В-третьих, хвост задержек тут определяется с самой медленной нодой и состоянием сети. В-четвёртых, при сетевых разрывах легко получить подготовлено в части участников, но не закомичено, и потом придётся разгребать

75:01

Speaker A

это вручную. Поэтому между микросервисами PC практически не используется, а вот внутри одной базы или кластера PC применим. Следующий протокол Free PC - это Free Comit Face.

75:16

Speaker A

Это попытка сделать PC неблокирующим за счёт добавления дополнительной фазы прекомиit. Сначала координатор проверяет готовность участников, готов, не готов, потом рассылает им намерение комитить прикомит. И только потом следует финальный комит. Идея в том, что участник, доживший до прекомит и не

75:36

Speaker A

получивший финальное решение, может принять самостоятельное решение ролбек или коit и не зависать бесконечно в состоянии prepaired, как в случае с 2 PC. Но это всё держится на довольно нереалистичных допущениях и сети, что в ней маленькие прогнозируемые задержки, плюс дополнительно усложняет реализацию

75:59

Speaker A

и всё равно плохо бьётся с реальным продом. Поэтому free PC также очень редко можно встретить в настоящих микросервисах. Ты можешь сказать: "Антон, ну какого хрена ты тогда это рассказываешь?" А потому что это те самые академические знания, которые у

76:16

Speaker A

вас могут спросить на собеседовании, даже учитывая то, что в продакшене это не используют. TCC try confirm cancel - это прикладной паттерн распределённые транзакции на уровне бизнес-логики.

76:31

Speaker A

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

76:48

Speaker A

Confirm: зафиксировать операцию после успеха всех trй и CCEL снять резерв, если кто-то из участников не прошёл TR или произошёл сбой. Важно, каждый микросервис должен иметь отдельные endпоинты или методы, cancel confirm, хранить состояние резерва. ID-операции, объём, срок жизни и уметь корректно обработать повторные

77:14

Speaker A

вызовы и домпотентность. В отличие от 2PC, здесь нет блокировок в СУБД. Подготовленное состояние живёт в бизнес-данных, а протокол не привязан к конкретной базе и может работать с разными стеками. TCC применяется там, где цена ошибки очень высока. Это финтех бронирование билинг управление

77:37

Speaker A

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

78:01

Speaker A

откат. Пример для оформления заказа. Билинг списывает деньги. Inventory резервирует товар, orders создаёт заказ. Notifications отправляет письмо или push. Если на шаге два не удалось зарезервировать товар, вызываем компенсацию в билинге. Refund или снятие холд. Если на шаге три упало создание

78:25

Speaker A

заказа, можно вернуть деньги либо, если домен операции не позволяют автоматический возврат, сделать напрямую компенсацию. Например, отправить задачу менеджеру, письмо в саппорт, сигнал в CRM. Дальше человечек разруливает ситуацию. Компенсация при этом не обязана быть симметричной обратной операцией. Главное, чтобы процесс

78:48

Speaker A

приходил в согласованное состояние по бизнес-правила. Что даёт нам сага? Нет глобальных блокировок и подготовленных состояний. Шаги отдельные можно компенсировать, мониторить или ретраить.

79:02

Speaker A

удобно масштабировать процессы между разными сервисами и стеками. Цена здесь сложность самого процесса и продуманность сценариев компенсации.

79:12

Speaker A

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

79:39

Speaker A

задержек. И процессные паттерны Sag Outbox Event Driven, которые упрощают жизнь сервисом, но делают расхождение между их состояниями нормой. На уровне данных это выглядит так. Есть куски, где нам нужна более строгая консистентность.

79:55

Speaker A

Это балансы, права доступа, критические инварианты. И это вид согласованности Strong consistency. И есть всё остальное, где мы готовы жить с тем, что разные сервисы некоторое время видят разное состояние данных. Это eventual consistency. Знать это нужно. Ну, во-первых, для собеседований, а

80:19

Speaker A

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

80:29

Speaker A

Но я схожу с ума потихоньку уже от этих слов. У меня вытесняются детские воспоминания, имена родителей. Я помню только, [ __ ] консиistнcy, хуистенси, хвосты задержек и прочую залупу. Я больше так не могу. Итак, eventual Consistency - это модель, которая

80:48

Speaker A

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

81:13

Speaker A

отобразиться не сразу, но в целом никто от этого особо сильно не пострадает. Что нам даёт эта модель? Ну, во-первых, высокую доступность. Не нужно блокировать всю систему из-за одной реплики. Более простое масштабирование.

81:27

Speaker A

Можно шардировать и реплицировать без глобальных транзакций. Низкую стоимость записи, меньше блокировок, меньше координации. Также существуют локальные приёмы. которые помогают снять боль конкретного запроса или конкретного пользователя от потенциального расинхрона в этом подходе eventual consistency. Поэтому в большинстве случаев он неплох. Теперь про Strong

81:54

Speaker A

consistency. Это более жёсткая модель, которая нам пригодится, когда речь идёт о деньгах пользователя, например, или ограниченных ресурсах вроде гостиничных номеров. Потому что, согласись, будет очень неловко, если два пользователя одновременно увидят свободный номер.

82:13

Speaker A

Первый забронит, у второго не отобразится, что он уже забронен, и в итоге потрачено. Все очень недовольны.

82:21

Speaker A

Её также используют, когда работают с критичными правами доступа и операциями, компенсация которых невозможна. Суть её в том, что если запись успешно прошла, то любое последующее чтение должно видеть новое значение этого ключа, вне зависимости от узла, на который пришёл

82:41

Speaker A

запрос. Также есть ещё более строгий её вариант линиаризуемость - это когда вдобавок сохраняется ещё и правильный порядок операций. Главный минус таких систем - стоимость, доступность и сложность масштабируемости. на практике почти никогда не делают всю систему жёсткой. Реализуют небольшой слой или

83:02

Speaker A

сервис уровня strong, например, бронирование конкретного места на рейс, а вокруг сервисы с eventual consistency, например, предзаказ еды. И напоследок возвращаемся. Мы с тобой в красной комнате. Если что, я Кристиан Грей, а ты Анаastши Стил. И вот вопросы, которые

83:23

Speaker A

тебе могут задать на собеседовании. В чём разница между паттерном SGA и two PC? Какую проблему решает free PC? Какие группы решений проблемы согласованности существуют в принципе и в чём их особенности? Приведи по примеру системы, в котором ты бы использовал эти группы

83:45

Speaker A

решений проблемы согласованности. В предыдущих частях мы говорили про кэш на уровне redes. Он ускоряет запросы к базе. В целом это правда, но очень поверхностно. Кстати, вы можете обратить внимание, как уровень моего IQ постепенно растёт с ходом этого гайда,

84:04

Speaker A

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

84:20

Speaker A

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

84:31

Speaker A

При этом хвосты задержки и кросс-шарды мы как раз и пытаемся лечить кэшем. например, спрятать медленные запросы, уменьшить фанаут, не ходить по всем шардам и не считать тяжёлые агрегаты на лету. Но любой кэш добавляет ещё один слой eventual consistency, потому что

84:48

Speaker A

данные в нём почти всегда не совсем как в базе. Поэтому открываются новые способы выстрелить себе в ногу, если спроектировать его невнимательно. Для примера я буду использовать marркетплейс с миллионами товаров, корзиной, заказами, то, чем все мы пользуемся.

85:05

Speaker A

Короче, как в реальной жизни. Начнём с тупого вопроса. Если ты уже расслабился и заскучал. Зачем вообще нужен кэш в продакшене? Кэш нужен для разгрузки базы данных и внешних. Вместо 100.000 запросов в секунду делаем 100 и не дедосим нашу систему. Ускорение чтений.

85:25

Speaker A

Карточка товаров читается за 2 мисекунды вместо птися из нашей БД. Переиспользование дорогих тяжёлых вычислений. рекомендации, отчёты и агрегаты. Представь, ты Татьяна Бакальчук. Ну всё. А вы думали, там какой-то пример будет? Представь, ты Татьяна Бакальчук, у тебя marркетплейс, и тебе на каждый заказ чехла для

85:49

Speaker A

смартфона из Китая нужно показывать актуальный курс валюты. Вы интегрировались с каким-то внешним АИ для актуальных курсов. И вот проблема. У вас 200.000 активных пользователей. И на каждый просмотр карточки товара или оформление заказа нужно дёргать эту внешнюю ручку, чтобы показать текущий

86:08

Speaker A

курс. Внешний IP может из-за этого упасть. Он в целом может тормозить или даже заблокировать вас за DDOS. Решение.

86:17

Speaker A

Отдельный воркер раз в минуту запрашивает актуальный курс валют и кладёт их в redс. Все запросы пользователей читают этот курс из кэша, а не лупят во внешней IP. У нас тут не биржа и изменение курса на 001 нам не

86:33

Speaker A

очень интересно, поэтому решение нормальное, а конкретная сумма будет уточнена там один раз, когда будет совершена оплата. Ещё иногда имеет смысл кэшировать не только успешные ответы, но также и ответ ничего нету. Классический пример стороння IP каталога. Мы спрашиваем карточку товара и стабильно

86:54

Speaker A

получаем 404 not found. Логично не ходить за тем же ответом по 100 раз в минуту, а закэшировать пустой результат на короткое время. А вот что не стоит кэшировать. Сетевые сбои, та conneнеction reset, временные ошибки сервера, то есть пятисотые. Короче, всё,

87:12

Speaker A

что очевидно, связано с деградацией системы, а не данных реально нету. Такие ошибки должны лечиться ретраями, circuit breakрами и алёртами, а не превращаться в кэш. Иначе мы рискуем закрепить временную ошибку как новую норму. Ещё несколько кейсов, где кэш бесполезен и

87:33

Speaker A

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

87:47

Speaker A

Критично консистентные данные - это балансы, лимиты, права доступа, где даже небольшое различие недопустимо. коротко живущие данные, одноразовые токены, временные статусы с ТТЛ пару секунд.

88:02

Speaker A

Теперь давайте перейдём к теме посложнее. Многоуровневое кэширование и оптимизация. Наша цель по задержке простая. Мы хотим отдавать данные как можно ближе к пользователю, раньше по пути запроса. Чем раньше попали в кэш, тем быстрее ответ и тем меньше нагрузка

88:20

Speaker A

на другие слои. На схеме можно увидеть несколько уровней кэша от браузера до базы. Пройдёмся по каждому и разберём, что где хранится. Первое- браузер или клиент. Ближайший к пользователю слой кэш живёт на клиенте, чаще всего в браузере. Здесь обычно лежат статика,

88:36

Speaker A

джаваскрипти сес-шрифты картинки товаров и оффлайнданные через сервис Worker. CDN второй слой кэш на границе нашей системы и интернета. CDN серверы.

88:46

Speaker A

На этом уровне храним медиа, фото, видео, другие файлы. CDN отвечает с узла географически близкого к пользователю и сильно разгружает Origin по трафику и времени ответа. L1 in Progress кэш в памяти приложения. Третий слой L1 кэш прямо в процессе приложения. На каждой

89:05

Speaker A

ноде отдельно. Сюда хорошо заходят небольшие справочники, категории, статусы, права текущего пользователя, фича, флаги, конфиги, приложения. Этот кэш самый быстрый. По задержке менее 1но мисекунды, но локальный. У каждого инстанца свой набор данных, не связанный с другими инстанцами. L2 Redis.

89:25

Speaker A

Четвёртый слой общей кластерный кэш. Обычно Redis. На этом уровне держим топ товаров агрегаты счётчики рейтинги результаты поиска и другие тяжёлые вычисления. Redis тут выступает буфером между горячим онлайн-трафиком и базой.

89:43

Speaker A

Меньше походов в БD, меньше нагрузки на диск и ниже шанс поймать хвосты. Пятое. База данных. Последний слой. Сама база данных. Наш источник правды. В ней живут истинные данные, индексы, материализованные вьюхи и прочие структуры под сложные запросы. До базы

90:02

Speaker A

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

90:22

Speaker A

observability или наблюдаемость. В первую очередь хитрей, то есть процент запросов, которые нашли данные в кэше, и задержка по слоям. Это очень важно для сабесов по системному дизайну высокого уровня. От тебя там ждут не просто, ну давайте положим всё вредис. Кэш - это круто.

90:41

Speaker A

Кэш ready readyс кэш. А умение объяснить, какой или какие слои кэширования мы будем использовать, какие данные положим на каждый из них, чем мы платим за согласованность между этими слоями и за счёт чего выигрываем по задержке и нагрузкам. В рамках темы

90:59

Speaker A

также важно рассмотреть понятие cash cerence или согласованность кэша. Это свойство системы, при котором все копии одного и того же объекта данных остаются в разных кэшах согласованными.

91:13

Speaker A

Расхождение кэша может проиллюстрировать такой кейс. Допустим, ты решил заказать немножко хрючево, когда вы с друзьями тусите у тебя на даче, выбрал уже всё, вбил новый адрес, но из кэша подтянулся твой старый адрес, то есть домашний. В результате поддержка отказывается

91:30

Speaker A

отменять заказ. Курьер уже его привёз, ничего нельзя поделать. Вернувшись с дачи через 4 дня, ты обнаруживаешь у двери стухшие роллы, что, конечно же, несколько демотивирует тебя. Как же великолепному сервису и экосистеме Яндекседа избежать этой проблемы? Есть два разных подхода: Cash Driven и

91:50

Speaker A

Service Driven. И из этих подходов рождаются четыре разных стратегии наполнения кэша. Стратегия первая Cash Aside или другое название Lazy Loading, то есть ленивая загрузка. При этом подходе всем управляет сервис. То есть наш код явно проверяет кэш, если там

92:12

Speaker A

пусто, обращается к базе данных, кладёт данные в кэш и сам же сервис делает invalidate. Всё отлично работает, пока у вас две страницы. Потом становится всё сложнее этим управлять, так как логика размазана по коду. Стратегия два. read through C или сквозное кэширование в

92:30

Speaker A

какой-то момент становится более поддерживаемым решением сдвинуть эту логику в redдис. Для нашего сервиса всё становится куда проще. Мы тупо обращаемся в кэш. Если там данных нет, то он сам эти данные подтягивает и обновляет. Эта стратегия получше предыдущей, потому что нам не

92:49

Speaker A

нужно бегать по коду и искать, где добавить, убрать инвалидацию. Согласованность между редисом и базой данных становится стабильнее. Нет шансов записать в кэш устаревшие данные руками.

93:01

Speaker A

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

93:17

Speaker A

То есть пользователь, который только что обновил адрес, увидит старое значение до следующего Cash Miss. Стратегия 3. Total War Warhammer 3. Потрясающие расы, суперпроработанные механики, на мой взгляд, ну просто рассвет игроиндустрии, а конкретные серии Total War. Понимаю, что немногим нравится фантезийный

93:40

Speaker A

сеттинг, но если вы чуть-чуть отойдёте от своего старого Рима или Сёгуна второго, то нереально. А, стратегия три, Write through или сквозное кэширование с записью. Проблему предыдущей стратегии можно исправить, используя эту. Как она работает? Запись идёт в кэш. Кэш

93:59

Speaker A

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

94:07

Speaker A

Если дис упадёт, то мы не сможем больше писать в базу. И если база тормозит, то Редису тоже приходится ждать. Другая проблема - высокая латентность на запись. Мы сначала пишем в кэш и только потом в базу данных. Из-за этого

94:22

Speaker A

стоимость такого решения высока. Стратегия четыре. W right behind или right back casш или отложенная запись.

94:31

Speaker A

Как вы уже могли догадаться, эта стратегия решает проблемы предыдущей стратегии, но добавляет свои. Что происходит здесь? Запись делается только в кэш. Кэш кладёт операцию в очередь. BD обновляется фоново через батчи. Таким образом, запись у нас снова становится быстрой. БD можно обновлять батчами, что

94:51

Speaker A

дёшево. Из минусов мы сознательно уходим от сильной консистентности в пользу задержки и пропускной способности. Можно использовать либо в eventual consistency, вроде сага, либо для данных, которые допустимо терять. аналитика, логи и тому подобное. Происходит неконсистентность в обратную сторону. В КШе свежее, чем в

95:18

Speaker A

базе данных. Возникает риск потерять данные, если упадёт очередь. Итак, мы разобрались, как писать кэш с необходимым нам уровнем когерентности, а как удалять данные из кэша. Ведь, как говорится, в программировании есть только две сложные проблемы: инвалидация кэша и придумывание названий. А, поняли?

95:41

Speaker A

И в первой проблеме нам доступно три подхода. TTL only. Самый простой, но самый неэффективный подход - это TTL only. При этом подходе мы вообще не инвалидируем кэш явно, просто ждём, пока срок его жизни истечёт. Зато нам не нужно писать здесь лишний код или

96:01

Speaker A

придумывать какую-то архитектуру. Этот подход приемлем для ленты новостей, каталогов, товаров, но ужасен для адресов доставки, балансов и лимитов.

96:11

Speaker A

Eventbas based invalidation, то есть ситуативное аннулирование кэша. Здесь сразу после изменения данных мы отправляем события, а подписчики решают, что делать. Подписчики - это не вы, это в паттерне вот эти вот подписчики. Например, подписчики могут удалить ключ, обновить кэш, сбросить локальный L1, отправить

96:33

Speaker A

обновление в CDN, инвалидировать связанные ключи. Тег based invalidation, ну или что-то типа тегов кэша. Итак, подписчики умеют инвалидировать связанные ключи. Но как это работает?

96:45

Speaker A

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

97:04

Speaker A

нужен кэш? В каких ситуациях он делает только хуже? Какие уровни кэша существуют и что на них хранится?

97:11

Speaker A

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

97:26

Speaker A

тайм-коду и ещё раз прослушай важный материал. Эти вопросы почти наверняка попадутся на собеседовании по системному дизайну.

97:37

Speaker A

За предыдущей части мы с вами уже расковыряли кэш и консистентность. Посмотрели на распределённые транзакции, поговорили про шардирование и производительность. Теперь честный вопрос: что мы за это платим? Платим мы всегда одними и теми же вещами. Это CPU, память и кэш, диск и сеть, сложность

97:59

Speaker A

системы и банально деньги. И всё это при этом как-то должно укладываться в наш SLO. То есть service level objective, внутренние цели по задержкам и доступности и обещание наружу, то есть SLA, Service Level Agreement, если мы их даём. Вопрос, который часто задаётся на

98:19

Speaker A

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

98:36

Speaker A

Оптимизация ресурсов в реальных системах - это не выжить 100% CPU, а выбор, на что именно мы будем тратить ресурсы, чтобы уложиться в СЛО по задержкам и доступности. Начнём с самого любимого графика всех менеджеров. Утилизация CPU.

98:54

Speaker A

Запрос обычно такой: приходит эффективный менеджер и говорит: "А что у нас с CPU 40-50%? Давайте оптимизируем, чтобы было хотя бы 8090, а то железо простаивает". Звучит логично, пока мы не вспоминаем теорию очередей. И вот тут наш первый ресурсный трейф. С одной

99:10

Speaker A

стороны, у нас есть сервисы, нетерпимые к задержкам: UIP, авторизация и чекаут. Поэтому мы сознательно оставляем headдroom по CPU 40-60%, иногда 60-70. Не гоняемся за стопроцентной утилизацией, платим за недоиспользуемое железо, покупаем предсказуемые хвосты и запас на пики. С другой стороны у нас батчи и аналитика,

99:37

Speaker A

оффлайн обработка. Тут мы можем смело жить на 80-90% CPU. Хвосты там почти не важны. Нам важнее, чтобы джаба закончилась к утру.

99:48

Speaker A

Математически это одна и та же кривая, архитектурно- два разных решения. Следующий любимый способ оптимизировать ресурсы - это сказать: "А давайте мы всё закэшируем и проблема с производительностью уйдёт". Технически идея верная. Хороший кэш повышает пропускную способность и снижает нагрузку на BD и внешний API. За счёт

100:11

Speaker A

этого выигрываем и по задержке, и по стоимости нижних уровней. Но у этого компромисса три стороны. Первое, память.

100:19

Speaker A

Больше кэша, значит, нам нужны жирнее инстансы и больше not. Вторая сложность, инвалидация. Тt- согласованность между уровнями Cash Stampit, Thundering Hurt, Callessing, Perk Muteics. Всё это стоит денег и человека часов. И третье - это риски хвостов. Промахи по кэшу на

100:42

Speaker A

горячих ключах могут устраивать локальные штормы. Например, 1.ся запросов мимо кэша идут в БД, рост очередей и девяносто девятого персентиля в те моменты, когда кэш дымит. В итоге наш трейдоф выглядит так. Хотим меньше грузить БД и внешние сервисы.

101:03

Speaker A

Увеличиваем кэш. Платим за память и за сложность инвалидации. Хотим простую систему и дешёвые машины. Уменьшаем кэш.

101:12

Speaker A

Платим ростом нагрузки на нижние уровни и потенциальными хвостами при промахах. Здесь крайне важно не скатиться в религию. Всё кэшируем. Кэшировать имеет смысл горячие данные, часто читаемые и относительно стабильные.

101:28

Speaker A

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

101:48

Speaker A

работать. А дальше начинаются решения, за которые мы платим ресурсами. Например, типичный трейдоф с индексами.

101:55

Speaker A

Хотим быстрые селекты и гибкие запросы. Добавляем индексы, вьюхи и денормализацию. Платим пропускной способностью записи и сложностью обновлений. Хотим максимально быстрые записи. Режем индексы, меняем модель данных, усложняем жизнь нашему фронт и переносим логику в приложение. Дальше любимое. Давайте сделаем мультирегион,

102:20

Speaker A

чтобы не падало. Здесь мы берём метрики RPO. Сколько данных мы готовы потерять в случае падения и РТО, за сколько времени система должна подняться после падения?

102:32

Speaker A

Oof тут следующий. Хотим РПО приблизительно равное нулю и РТО меньше 10 минут. Платим дополнительной задержкой, сложностью топологии и счетами за облако. Готовы мириться с большим временем восстановления в случае катастрофы. Держим всё попроще и подешевле. И опять же это должно

102:51

Speaker A

опираться на СЛО. А не на веру. Если у вас продукт, который спокойно может пережить 1-2 часа даунтайма раз в год, то агрессивный мультирегион с синхронными кворумами будет избыточным усложнением системы. И, наконец, ещё один важный ресурс - мозги и время вашей

103:12

Speaker A

команды. Любая умная оптимизация ресурсов выглядит примерно так: динамический контроллер конкурентности, хитрый автоскейлинг по десяти метрикам, несколько очередей с приоритетами, pressure, который то душит, то отпускает сервисы, десятки конфигов, в которые страшно смотреть. Цена, которую мы платим, система становится непрозрачной.

103:34

Speaker A

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

103:44

Speaker A

Альтернатива- примитивная, но чуть переобеспеченная архитектура. Простая модель масштабирования, горизонтальный скейл по CPU или нагрузке. Чуть больше машин, чем минимально необходимо.

103:57

Speaker A

Минимальное количество умных контроллеров и автоматики. Очередной трейдоф. Хотим максимально выжить ресурсы, усложняем систему, платим временем и рисками. Хотим простую управляемую систему, переплачиваем за железо, но экономим на людях и авариях.

104:15

Speaker A

Все эти трейдофы завязаны на очень простой вопрос. Какие СЛО мы берём на себя и какие счета мы готовы за это платить в деньгах и в сложности. Ровно в таком виде это и прилетает на собеседованиях по архитектуре. Что вы

104:32

Speaker A

упростите и чем пожертвуете, если нужно в два раза удешевить инфраструктуру? Что будем менять, если бизнесу критичнее латентность, чем консистентность отчётов? Где вы согласитесь на более сложную архитектуру, чтобы не платить за железо? Важно помнить, тут не нужно я хочу быстро и надёжно и дёшево. нужны

104:55

Speaker A

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

105:16

Speaker A

места, какой будет RPS, выдержит ли сеть, диск и во сколько это выльется в инфраструктуре. Тут не ожидается какой-то суперточный расчёт с десятью цифрами. После запятой ожидается умение прикидывать порядок величин, понять, о каких десятках гигабт, 1.000х RPS идёт речь ещё до того, как вы что-то

105:38

Speaker A

задеплоили. Это я как бы объясняю, что не получится сжать этот гайд до топ-10 правильных ответов на собеседование по системному дизайну. Потому что, к сожалению, когда добавляется новая условность в этот вопрос и новое обстоятельства, нужно уметь быстро принимать решение и объяснять его

105:59

Speaker A

мотивацию самостоятельно. И как-то заранее это выучить сложно. Даже если тебе быстро нужно посчитать CPU, это возможно. Логика здесь будет такой.

106:08

Speaker A

Берём цель по девяносто пятому перцентилю задержки и RPS. Измеряем, сколько CPU, ядр нужно одному инстансу, чтобы выдерживать, скажем, 100 RPS с нужным девяносто пятым перцентилем.

106:20

Speaker A

Масштабируем по формуле из закона Litla. Нужен запас, поэтому не грузим выше 60-70% CPU. Далее мы переводим это в деньги. BD Noda класса 8 VCPU, 32 ГБ RAM, быстрый SSD - это десятки, сотни долларов в месяц в любом облаке. Плюс несколько

106:41

Speaker A

анот поменьше, плюс cluster. Не принципиально, по каким ценам ты будешь это считать. Важно иметь сам навык.

106:49

Speaker A

Прикинуть размеры таблиц, прикинуть RPS и трафик, понять, куда упирается система диск CPU сеть назвать порядок стоимости. Это инфраструктура на несколько сотен, тысяч, сотен тысяч долларов в месяц при таких-то SL. На архитектурных сабесах это и есть ожидаемый уровень ответа. Не точный

107:12

Speaker A

прайс-лист, а внятный численный сетичек, что система вообще реалистична и влезает хоть в какие-то бюджеты.

107:25

Speaker A

Привет, меня зовут Шпак Артём. Я сеньор системный аналитик и ментор. Давайте поговорим про роль системного дизайна в работе аналитика или как от роли сборщика требований перейти к роли архитектора решений. И главное, зачем вам вообще это нужно. Ключевой скачок

107:40

Speaker A

для миid аналитика на пути к сеньору и архитектору - это переход от ответа на вопрос: что мы делаем к способности самостоятельно отвечать на вопрос: "А как мы это будем делать?" Это значит, что вы перестаёте быть просто транслятором требований. Когда вы

107:56

Speaker A

собрали информацию, формализовали её, userсто или US, согласовали и передали на разработку, вы становитесь тем, кто может эти требования технически обработать, составить архитектуру, спроектировать все интеграции и выдать разработчикам такое техническое задание, по которому у них практически не останется вопросов. Конечно, небольшие

108:16

Speaker A

уточнения будут всегда, но общая концепция именно такая: создать настолько понятную документацию, чтобы команде оставалось просто брать и делать. Зачем это нужно для вашей карьеры и ценности на рынке? Понимание системного дизайна открывает для аналитика несколько путей роста и значительно повышает вашу стоимость как

108:35

Speaker A

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

108:53

Speaker A

без посторонней помощи. Вторая траектория роста в менеджера продуктунера руководителя. Здесь системный дизайн даёт вам большое преимущество уметь оценивать сложность и объём продуктов не просто по списку фич, а по компонентам и необходимой инфраструктуре. Вы начинаете понимать, почему продукт с одними и теми же

109:12

Speaker A

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

109:29

Speaker A

систем. Умение проектировать системы - это уже не просто плюс, а ожидаемый навык для высокооплачиваемых позиций.

109:37

Speaker A

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

109:52

Speaker A

остальных. Также упомяну, что становиться более высококлассным аналитиком важно ещё и потому, что цена ошибки аналитика на ранних этапах проектирования ПО очень большая.

110:01

Speaker A

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

110:10

Speaker A

Если архитектурный просчёт обнаружится на поздних стадиях, это может потребовать значительных доработок, что, конечно же, приведёт к потере времени и денег.

110:22

Speaker A

Также обязательно поговорим про работу с требованиями, что вы уже должны уметь. Во-первых, у вас, как у аналитика, должны быть базовые вводные. Вы умеете собирать требования, формализовывать их и грамотно взаимодействовать с заказчиком. Это фундамент. Если вы не умеете собирать требования, вы не

110:39

Speaker A

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

110:56

Speaker A

приносят, и он своей мудрой рукой пишет ТЗ: "Нет, вы должны быть в продукте, в процессах, глубоко погружены в задачи бизнеса и всегда взаимодействовать с заказчиком. Это первая и постоянная обязанность". Давайте перейдём к разбору каждого этапа жизненного цикла ПО с

111:12

Speaker A

упором на системный дизайн. Во-первых, участие в Discovery. Если мы говорим о жизненном цикле ПО, то аналитик в самом начале не просто собирает требования.

111:22

Speaker A

Если продукт новый или фича крупная, а не просто небольшая доработка, то на этапе Discoverovery нужно проверить жизнеспособность идей. Это критически важно. Оценить реализуемость и сложность, чтобы не тратить месяцы и ресурсы на заведомо бесперспективный проект. Кто может это делать? Аналитик,

111:41

Speaker A

архитектор, тех, в общем, человек, который понимает и продукт, и потребности бизнеса, и основы проектирования систем. Он должен дать честную оценку. Возможно ли это реализовать, насколько это сложно, какие риски и ограничения. Разберём пример Discovery. Бизнес приходит и говорит: "Мы хотим собирать аналитику по каждой

112:00

Speaker A

покупке на маркетплейсе в реальном времени и сразу же на её основе показывать рекомендации пользователю".

112:06

Speaker A

Звучит классно, но давайте разберём. Это real time сценарий, то есть покупка фиксируется. Система мгновенно должна обработать события, сделать расчёты рекомендаций и выдать новые рекомендации прямо на глазах у пользователя. Что же это значит для нас? Это высокая нагрузка, постоянные вычисления на лету,

112:26

Speaker A

сложная архитектура и дорогостоящая инфраструктура. Реализовать можно, но это не просто. Задача аналитика - донести это до бизнеса, показать, что такие требования автоматически тянут за собой рост стоимости и сроков, и задать правильный вопрос: действительно ли критично выдавать рекомендации прямо в

112:45

Speaker A

момент покупки? А теперь предложим альтернативу. Мы можем собирать данные по каждой покупке, но обрабатывать их асинхронно. То есть покупки копятся в системе, данные агрегируются и периодически пересчитываются. И уже после этого пользователю выдаются рекомендации, например, на следующий визит или даже через несколько минут.

113:06

Speaker A

Что здесь важно? Асинхронный подход проще, дешевле и быстрее в реализации. Да, вау эффекта реалтайма не будет, но бизнесу придётся решить, насколько он готов инвестировать ради этого эффекта.

113:19

Speaker A

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

113:35

Speaker A

Перейдём к работе с функциональными требованиями. Соответственно, чтобы уметь это делать, у вас должны быть базовые навыки системного аналитика.

113:43

Speaker A

Первое- уметь собирать и формализовывать функциональные требования так, чтобы они были понятны разработчикам. Здесь важно не просто зафиксировать хотелку бизнеса, а провести декомпозицию, то есть разбить большую идею на конкретные ключевые возможности. Например, бизнес говорит: "Хотим программу лояльности с баллами и

114:03

Speaker A

уровнями". Аналитик должен разложить это на части: начисление баллов, списание баллов, система уровней и переход между ними, правил отображения статуса пользователю. И только после такой декомпозиции у команды разработки появляется чёткое понимание, что именно нужно реализовать. В помощь вам формализация через популярные

114:22

Speaker A

проверенные инструменты user story, use BPMNдиаграммы, activity диаграммы, CASE диаграммы. Эти нотации позволяют структурировать требования так, чтобы и бизнес, и разработчики говорили на одном языке, но на этом работа не заканчивается. Второе - это умение работать с нефункциональными требованиями. И тут мы выходим на

114:43

Speaker A

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

115:01

Speaker A

бизнес говорит: "Приложением будет пользоваться 1.000 пользователей, архитектура может быть одна. Если нам нужно обработать 100.000 тысяч пользователей, то архитектура будет совсем другая. Именно учёт нефункциональных требований превращает аналитика в человека, который действительно понимает, как система будет работать в реальных условиях.

115:21

Speaker A

Предлагаю разобрать основные нефункциональные требования. Во-первых, это, конечно же, производительность. Насколько быстро система должна отвечать пользователю? Вопрос, который нужно задать, чтобы выявить это требование, сколько времени допустимо ждать ответа результата? Пример формулировки. данного требования ответ должен приходить сразу же моментально или ответ должен

115:43

Speaker A

приходить в течение минуты. Примертрик данного требования. Например, среднее время ответа меньше 200 мкунд. Как это влияет на архитектуру? Мы будем использовать кэширование, inmemory кэширование, индексы в базе данных, оптимизация запросов, CDN хранилище.

115:59

Speaker A

Второе требование - это пропускная способность. Это сколько действий запросов система может обрабатывать в секунду. Какой вопрос необходимо задать, чтобы выявить это требование? Сколько запросов транзакций в секунду в пике должна выдерживать система? Или сколько пользователи максимально будут пользоваться сервисом одновременно?

116:16

Speaker A

Пример формулировки требований. Система должна выдерживать 5.000 запросов в секунду. Ну и, соответственно, как это можно измерить? Это RPS, количество запросов в секунду и как это будет влиять на архитектуру. При высокой нагрузке мы используем балансировки нагрузки, очереди, брокеры сообщений,

116:33

Speaker A

горизонтальное масштабирование. Следующее требование - масштабируемость. Это насколько легко система может расти при увеличении пользователей, запросов и нагрузки. Как выявить это требование? На сколько раз и за какой срок вы ожидаете рост нагрузки, например, там за 12 месяцев? Ожидаются ли какие-то точечные

116:50

Speaker A

всплески, например, как чёрная пятница или новогодние акции? Пример формулировки: система должна горизонтально масштабироваться и выдерживать рост нагрузки в четыре раза в течение 12 месяцев. Примертрик, например, время запуски новой ноды или сервера. как это будет влиять на архитектуру. Сервисы не будут хранить

117:08

Speaker A

состояние. За счёт этого можно будет очень хорошо масштабироваться горизонтально и запускать новые ноды сервисов. Следующая метрика - это доступность. Насколько часто система должна быть доступной? Как выявить это требование? Спросить, какой процент времени система должна быть доступна?

117:24

Speaker A

Есть ли какой-то допустимой простой системы для технических работ и обновлений? Пример формулировки SL 99,95.

117:31

Speaker A

максимально простой 4,5 часа в год. Какие метрики используются для подсчёта данного требования? Это SLI - это процент успешной работы сервиса. Как это влияет на архитектуру и разработку? Мы используем резервные инстанции, реплики, мониторим состояние, ставим алерты, хлс-чеки. Состояние сервисов проверяется

117:49

Speaker A

автоматически. То есть, если что-то упало, вырос фон ошибок, мы об этом должны узнать и починить. Следующее нефункциональное требование - это объём и срок хранения данных. То есть это сколько места нам понадобится для данных и как долго мы будем эти данные хранить.

118:02

Speaker A

Какие вопросы стоит задать, чтобы выявить это требование? Какие данные и как долго мы должны хранить по закону для бизнеса? Что делать с данными, когда они устареют: удалять или архивировать?

118:12

Speaker A

А также должны узнать количество пользователей, чтобы примерно рассчитать размер диска для обработки запросов от данных пользователей. Пример формулировки требований. Система должна быть рассчитана на хранение 1 ТБ данных в первый год с возможностью роста до 5 ТБ в течение 3 лет. И ещё пример. Данные

118:29

Speaker A

заказа хранятся 5 лет, после чего автоматически архивируются. Технические улоги хранятся оди год и потом удаляются. Какие метрики используем для работы с данным требованием? Это объём хранилища, срок хранения в годах, в месяцах. Как же это влияет на архитектуру? Это выбор подходящей базы

118:46

Speaker A

данных и хранилища, планирование затрат и масштабирования, настройка автоматических правил для архивации, удаления данных. Следующее требование - это консистентность данных. Насколько быстро все копии данных должны быть одинаковыми? Нужно ли, чтобы данные были точными сразу или можно подождать несколько минут? Какой вопрос надо

119:03

Speaker A

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

119:15

Speaker A

Балансовые и платёжные операции - строгая моментальная консистентность. Отчёт и аналитика допустимы небольшие расхождения. Пример метрики: время синхронизации. Допустимая задержка, например, меньше 20 минут для синхронизации отчётов. Как это влияет на архитектуру? Если нам нужна высокая консистентность, то мы выбираем о базы

119:33

Speaker A

данных. Дальше поговорим про безопасность. Безопасность отвечает за сохранность данных, за контроль доступа, за аудит, то есть кто какие действия делал, когда это было, как долго это хранить. Ну и вообще очень много критерией безопасности. Какие вопросы необходимо задать бизнесу, чтобы выявить

119:50

Speaker A

некоторые критерии безопасности? В первую очередь это вопрос про данные. Какие данные считаются секретными? То есть персональные данные, платёжные данные. Во-вторых, конечно же, кто и каким данным должен иметь доступ, как входит в систему админы, нужен ли второй фактор, ну и, конечно же, про аудит. То

120:07

Speaker A

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

120:20

Speaker A

Вторая формулировка. Доступ к панели администратора доступен только пользователям с ролю администратор через корпоративный аккаунт. Метрик безопасности очень много, например, процент покрытия кода тестами на безопасность. Пример формулировок, например, включить МТLS для всех внутренних и внешних соединений, внедрить ролевую модель и ССО для

120:40

Speaker A

админов. Следующее требование - конфиденциальность и соответствие требованиям регуляторов. Соответственно, это правило хранения, удаления, обработки персональных данных соответствующими законами. Как выяснить это требование? Задать бизнесу вопрос: есть ли регуляторные, то и законодательные требования по обработке и сохранению персональных данных? Пример

120:57

Speaker A

формулировки. Данные российских пользователя хранятся на серверах, расположенных в России. Должен быть функционал удаления данных по запросу в течение 30 дней. Как это влияет на архитектуру? должен быть функционал контроля сохранения обработки персональных данных, механизма удаления персональных данных по требованиям и

121:15

Speaker A

сроку хранения. Следующее требование - это логируемость, то есть что и как нужно фиксировать для разбирательств предоставления данных по запросу, как это выявить, какие события необходимо логировать, как долго эти события должны храниться у нас на серверах. Пример формулировки. Все операции по платежам

121:32

Speaker A

хранятся в системе 5 лет. Какую метрику можно использовать? Например, срок хранения логов. Как это влияет на архитектуру? Необходимо реализовать централизованный лог, например, ел.

121:42

Speaker A

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

121:50

Speaker A

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

122:06

Speaker A

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

122:25

Speaker A

метрику можно использовать для работы с данным нефункциональным требованием. Например, процент запросов с логами. Как это влияет на архитектуру? Мы используем Прометеус графану используем трассировку логов, централизованный алертинг при инцидентах. Ну и последнее требование на сегодня - это локализация, поддержка различных языков и локальных

122:43

Speaker A

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

122:54

Speaker A

Пример формулировки требований: интерфейс должен быть локализован на русском, английском и казахских языках. Также должны быть локализованы форматы DAT. и валюты под каждую сторону.

123:04

Speaker A

Примерrix - это процент переведённого локализованного интерфейса. Как это влияет на архитектуру и разработку? Мы используем функционал локализации, пишем и проводим тесты локализации. Приведу практический пример проверки реализации идей бизнеса. Теперь, когда мы немного познакомились с нефункциональными требованиями, мы можем рассмотреть такой

123:24

Speaker A

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

123:36

Speaker A

Результат Discovery. Аналитик вместе с архитектором начинают задавать уточняющие вопросы, чтобы оценить реальный масштаб задачи. Сколько курьеров у нас будет на линии в пиковое время? 1.000, 10.000? Как часто приложение курьера должно отправлять свои координаты? раз 10 секунд, раз 3

123:53

Speaker A

секунды. Ведь это влияет на плавность отображения. Сколько клиентов одновременно будут следить за своими заказами в час пик? И какие у нас получились выявленные критические нефункциональные требования. Это высокая нагрузка, 10.000 курьеров, отправляющих координаты каждые 3 секунды. Это более 3.300 запросов в секунду, которую нужно

124:11

Speaker A

принять, обработать. Обычная база данных может не справиться с такой нагрузкой. Это низкая задержка. Чтобы движение было плавным, координаты нужно не только быстро принять, но и почти мгновенно доставить клиентам. Нагрузка для отправки данных клиентом. Каждое из 3.300 обновлений в секунду нужно

124:28

Speaker A

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

124:48

Speaker A

базданных, отдельных сервисов и значительных затрат на разработку и поддержку. Необходимо оценить, а купит ли бизнес-ценность от этой фичи подобные инвестиции. Практический пример влияния нефункциональных требований на архитектуру. Одинаковые функциональные требования, но разные нефункциональные.

125:05

Speaker A

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

125:18

Speaker A

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

125:39

Speaker A

второй - это когда отчёт необходимо актуализировать в реальном времени. То есть нефункциональное требование звучит для этих вариантов так. Для первого отчёт должен быть готов каждый день к 9:00 утра. Для второго варианта данные в отчёте должны отставать от реальных не

125:54

Speaker A

более чем на 5 секунд. Соответственно, будут разные подходы к реализации. В первом данные собираются и обрабатываются большими порциями по расписанию раз в день. Во втором варианте данные обрабатываются непрерывно по одному событию раз за раз сразу после их появления. И будут

126:09

Speaker A

различные принципы работы. То есть для первого случая ночью по расписанию запускается скрипт. Он собирает все данные о продажах за прошедший день из основной базы данных. Он рассчитывает и сохраняет готовый отчёт. И утром руководитель видит статичный отчёт за вчерашний день. Для второго варианта

126:24

Speaker A

архитектура выглядит сложнее. Мы будем использовать брокеры сообщений. То есть мы будем ловить эти сообщения, эти события, которые приходят от системы, где произошла продажа. Дальше сервис консюмер будет потокосчитывать эту кавку, обрабатывать события и складывать это в аналитическую базу данных,

126:42

Speaker A

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

126:59

Speaker A

отчёт. Также при больших объёмах данных может понадобиться шардирование. То есть нам придётся разделять эту базу данных по какому-то принципу, например, по регионом либо по категории продаж. В общем, мы берём принцип, разделяем по нему, и данные хранятся распределённо по

127:14

Speaker A

шардам, и это тоже усложняет разработку и поддержку данной системы. И, соответственно, поговорим про сложность и стоимость. Первый вариант, где у нас используется SQL скрипты и планировщик задач, это будет дёшево и быстро. Второй вариант, он очень сложный и дорогой, то

127:29

Speaker A

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

127:46

Speaker A

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

128:02

Speaker A

Проблема. В банковском приложении можно было быстро нажать на кнопку перевести несколько раз, и система не проверяла уникальные запроса и создавала несколько одинаковых переводов, позволяя дюпать деньги. То есть баланс дебетовой карты уходил в минус. Почему это происходило?

128:18

Speaker A

Причина: отсутствовал ключ импотентности, уникальный идентификатор запроса, который позволяет серверу понять, что это повторный запрос и не стоит его обрабатывать дважды. Также отсутствует блокировка кнопки на фронте для защиты от случайных повторных нажатий. К какому выводу мы можем прийти? Нефункциональные требования.

128:37

Speaker A

Операция должна выполняться ровно один раз. Это критическое требование, которое аналитик должен выявить и зафиксировать.

128:43

Speaker A

Front должен блокировать кнопку от повторных нажатий, акэнд обязан проверять импотентность для защиты от повторных запросов.

128:53

Speaker A

Перейдём к проектированию решения. Итак, мы переходим от работы с требованиями к самому интересному: проектированию системы и оформлению детальной спецификации. В этом модуле мы разберём архитектуру, интеграции и работу с данными. Шаг первый: анализ и принятие архитектурного решения. На этом этапе мы

129:12

Speaker A

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

129:25

Speaker A

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

129:45

Speaker A

В чём суть? Мы вносим изменения в уже работающие сервисы. Какие есть плюсы? Быстро для небольших минорных изменений.

129:52

Speaker A

Минусы: можно сломать то, что работает, а также ограничено возможностями текущей архитектуры. Второй подход - это революция, создание нового. Суть в том, что мы пишем один или несколько новых сервисов с нуля. Из плюсов безопасно и гибко мы сможем полностью реализовать

130:08

Speaker A

всё, как мы хотим. Из минусов долго и дорого на старте. И третий подход - это гибрид. Интеграция нового в старое. Суть в том, что создаём новые компоненты и встраиваем их в существующую архитектуру. Из плюсов это самый частый сбалансированный подход. Это быстрее,

130:25

Speaker A

чем всё делать с нуля, но, конечно, медленнее, чем просто дорабатывать существующие компоненты. Когда этот вариант подходит? Идеально для больших фич, особенно если IT-ландшафт компании уже достаточно большой. Например, можно вынести что-то высоконагруженное в отдельный новый сервис. Второй шаг -

130:42

Speaker A

выбор паттерна проектирования. После того, как мы приняли стратегическое решение, например, выбрали революцию или гибрид, перед нами встаёт следующий ключевой вопрос: а как именно мы будем нарезать новую функциональность на отдельные сервисы? Просто сказать, делаем микросервисы недостаточно. Нам нужно чётко определить и границы. Именно

131:02

Speaker A

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

131:22

Speaker A

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

131:31

Speaker A

Паттерны декомпозиции. Они отвечают на главный вопрос: как разбить большую задачу на маленькие независимые сервисы?

131:39

Speaker A

Здесь два популярных подхода: декомпозиция по бизнес-возможностям - это самый простой и логичный способ для начала. Мы смотрим на то, что бизнес делает, и создаём сервис для каждой его функции. Например, в интернет-магазине есть возможности управление каталогом товаров, обработка заказов, управление

131:57

Speaker A

клиентами. Каждая из них становится отдельным микросервисом. Этот подход легко понять, потому что архитектура напрямую отображает структуру бизнеса.

132:06

Speaker A

Второй подход - декомпозиция на основе предметно ориентированного проектированию либо домен Divн Design. Этот подход сложнее глубже, чем первый.

132:14

Speaker A

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

132:21

Speaker A

Например, слово товар в контексте склада означает физический объект с весом и размером, а в контексте каталога на сайте - это описание, фото и цена. Дд предлагает сделать для каждого такого контекста свой сервис. Это помогает справляться со сложностью в очень

132:36

Speaker A

больших и запутанных системах. Паттерны взаимодействия. Они определяют, как сервисы будут общаться друг с другом.

132:43

Speaker A

Яркий пример Patтер App Gway, который создаёт единую точку входа для всех внешних запросов к системе, скрывая её внутреннюю структуру. Паттерны управления данными решают проблемы хранения и консистентности данных в распределённой среде. Например, паттерн база данных на сервис. Для системного

133:01

Speaker A

аналитика самый простой и понятный способ начать - это использовать паттерн декомпозиции по бизнес-возможностям. Его суть в том, чтобы выделить ключевые направления деятельности бизнеса и создать отдельный сервис для каждой такой возможности. Этот подход идеален для аналитиков, так как он напрямую

133:18

Speaker A

связывает архитектуру с бизнес-логикой. Приведу пример. Декомпозиция программы лояльности. Давайте вернёмся к нашему примеру. Бизнес хочет программу лояльности с баллами и уровнями.

133:29

Speaker A

Применим этот паттерн композиции по бизнес-возможностям. Сначала определим эти самые возможности. Управление баллами. Всё, что связано с начислением, списанием и расчётов баллов, управление уровнями клиентов, логика присвоения уровней: бронзовый, серебряный, золотой и переходов между ними. Управление акциями созданиями настройка специальных предложений, например,

133:52

Speaker A

двойные баллы по выходным либо в день рождения, информирование клиента, отправка уведомлений об изменении баланса или его уровня. Теперь сопоставим каждую возможность с будущим микросервисом. Первый - это Point Service, сервис баллов. Он будет отвечать за всю логику работы с баллами.

134:10

Speaker A

Второй Teвиice, сервис уровней, будет управлять статусами клиентов. Третий сервис - Promotion сервис, сервис акций, будет хранить и применять правила акций.

134:20

Speaker A

Ну и, конечно же, сервис, сервис уведомлений. Он будет отправлять email, push, SMS-уведомления, но это может быть уже существующий сервис, с которым мы просто интегрируемся и его немного доработаем. В результате этого шага мы получаем итоговый список сервисов.

134:35

Speaker A

Теперь мы чётко понимаем, из каких независимых компонентов будет состоять наша новая система. Этот список является фундаментом для следующего этапа.

134:43

Speaker A

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

134:58

Speaker A

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

135:18

Speaker A

это ящики, за что каждый из них отвечает и как именно они должны общаться друг с другом. Что происходит внутри каждого ящика? Это уже зона ответственности команды разработки. Первый уровень диаграммы - контекст. Цель - показать, где границы вашего продукта, кто что с

135:35

Speaker A

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

135:57

Speaker A

рисуем вашу систему в самом центре, как единый чёрный ящик. Мы пока не знаем, что у неё внутри, но знаем её название и основное предназначение пользователей акторов, которые с ней взаимодействуют.

136:08

Speaker A

например клиент администратор менеджер, внешние существующие системы, с которыми одна обменивается данными. Например, платёжный шлюз, SMS-провайдер, бухгалтерская система 1С. Основные потоки данных, стрелки. Что и в каком направлении передаётся? Давайте разберём легенду данной диаграммы. Пользователь, разрабатываемая система, внешние системы, связи. Вот пример диаграммы уровня

136:34

Speaker A

контекста для нашего примера с программой лояльности. Второй уровень- контейнеры. Ключевая архитектурная схема. Здесь мы приближаем нашу карту и заглядываем внутрь нашего чёрного ящика.

136:46

Speaker A

Этот уровень описывает технические блоки, из которых состоит система. Вернёмся к аналогии. Мы приблизили карту мира и теперь видим не просто страну, а её крупные города, регионы, главные транспортные магистрали между ними. Мы видим Москву - это наш сервис пользователей, Санкт-Петербург- сервис

137:03

Speaker A

заказов, Екатеринбург- скводская система и федеральные трассы, то есть интеграции, которые их соединяют. Разберём подробнее, что такое контейнер в C4. Это любая отдельно развёртываемая единица в нашей IT-системе. Если вы можете запустить или остановить что-то независимо от остального, скорее всего

137:22

Speaker A

это отдельный контейнер. Примеры контейнеров: приложения, это микросервисы веб-приложения мобильные приложения, это хранилище данных, база данных, например, Postg SQL, Cash в Редисе, интеграционные компоненты, брокеры, очереди сообщений.

137:40

Speaker A

Что рисуем? На этой диаграмме мы показываем, как эти контейнеры взаимодействуют для реализации системных сценариев. Это конкретные сервисы приложений и хранилища, новые существующие связи между ними. Каждая стрелка должна быть подписана и отвечать на два вопроса. Зачем? То есть краткое

137:58

Speaker A

описание бизнес-цели, запрашивать данные о пользователе, отправлять события об оплате и как технология протокол. Синхронно https, асинхронно кавка.

138:10

Speaker A

Перейдём к легенде данного уровня. Во-первых, это контейнер, группа контейнеров, из которых состоит документируемая система, хранилище данных, брокер или очередь сообщений.

138:21

Speaker A

Вот пример уровня контейнеров для нашего кейса с программой лояльности. Ключевая ценность для аналитика. Для системного аналитика - это главная архитектурная диаграмма. Именно здесь визуализируется ваше стратегическое решение. Появляются новые сервисы, которые интегрируются со старыми. Определяются границы ответственности каждого сервиса.

138:41

Speaker A

фиксируются все точки интеграции, которые затем нужно будет детализировать. Это финальная точка детализации архитектуры с точки зрения аналитика. На уровне контейнеров мы остановимся, потому что третий уровень, компоненты и четвёртый код описывают внутреннюю реализацию контейнера. Для аналитика это не так важно, потому что

138:59

Speaker A

то, как разработчики организуют код внутри сервиса одним модулем или пятью, является деталью реализации, которая не меняет его внешнего поведения и контрактов. Ваша задача - определить обязанности контейнера и его апи, а не его внутреннее устройство. Перейдём к четвёртому шагу. Проектирование

139:18

Speaker A

интеграции. Итак, мы определились компонентами, их связями на архитектурной карте. Теперь наша задача - превратить эти высокоуровневые стрелки в исчёрпывающее руководство для разработчиков. Цель- не оставить никаких белых пятен, чтобы реализация была быстрой, точной и предсказуемой. Этот процесс состоит из трёх последовательных

139:38

Speaker A

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

139:59

Speaker A

получить информацию о профиле пользователя перед заполнением заявки. Это взаимодействие требует мгновенного получения результата либо ошибки.

140:08

Speaker A

Синхронный вызов создаёт сильную временную связанность. Клиент не может продолжать работу, пока сервис-исполнитель не ответит. Если исполнитель лежит, то лежит и клиент.

140:18

Speaker A

Выбираем асинхронный подход. Если операция длительная и мы не хотим заставлять пользователя ждать, классические примеры: формирование годового отчёта, конвертация видео, скоринг в банковской системе для одобрения кредита, либо выбираем, если нужно повысить надёжность и разорвать жёсткую связь между сервисами. Если

140:37

Speaker A

сервис-получатель временно недоступен, то сообщение просто подождёт его в очереди, пока сервис оживёт. Либо выбираем, если одно действие должно запускать несколько независимых процессов в разных системах. Например, событие заказ оплачен должно запустить процесс сборки заказа на складе, списание бонусов, формирование чека и

140:57

Speaker A

создание заявки на доставку. Либо нужно построить надёжную, гибкую и независимую архитектуру. Сервис-отправитель просто оставляет задачу в очереди. Ему не нужно знать, кто её обработает, и работает ли получатель в данный момент, что повышает гибкость и надёжность всей системы.

141:14

Speaker A

После выбора паттерна мы определяемся с технологией, учитывая требования и стандарты, принятые в компании. Важно понимать, нет единого правильного решения, подходящего для всех случаев.

141:25

Speaker A

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

141:33

Speaker A

Где-то вся разработка ведётся на языке GO, и стандартом для внутреннего общения является GRPC. В другой компании может быть целый зопорк технологий, и универсальной интеграции для них служит REST https. Если выбран синхронный паттерн, то мы можем выбрать REST https.

141:48

Speaker A

Самый популярный и универсальный выбор, идеален для публичных, большинства внутренних АИ. Также стоит отметить, что с его помощью можно реализовать и некоторые асинхронные подходы, например, через полинг. GRPC - высокопроизводительный фреймворк. Он идеален для частого и быстрого общения между внутренними микросервисами. Если

142:08

Speaker A

выбран асинхронный паттерн, это у нас очереди, брокеры сообщений, Rabit MQ, Кавка. Это самые популярные технологии для построения надёжных асинхронных систем. Они позволяют отвязать сервисы друг от друга и гарантировать доставку или доступность прочтения сообщений.

142:25

Speaker A

Либо можем использовать вебсокеты. Это выбор для постоянного двунаправленного потокового соединения между клиентом и сервером. Например, чаты, биржевые котировки, курсы валют. После выбора технологии переходим к детализации, создания исчерпывающей спецификации нашей интеграции. Главная идея: у разработчика не должно быть двусмысленности. Какие параметры есть,

142:48

Speaker A

какие обязательные, какие форматы, как выглядит успешные и ошибочные ответы. Первый артефакт - это контракт интеграции а события сообщения.

142:58

Speaker A

Контракт - это детальное описание данных в интеграциях. Ключевая идея - детально описать структуру данных для любого взаимодействия между двумя сервисами, будь то, сообщение в Кавка или Websocket. Принцип всегда один: доточно задокументировать все параметры, их типы, форматы, обязательность, а также

143:19

Speaker A

примеры. Разберём описание контракта дляпи. Также хорошей практикой является описывать контракт с помощью спецификации OpenUp и Swager. На примере Rap в первую очередь мы описываем пути и методы. Это конкретные пути и HTP методы. Это и есть наш endpoint, например, post orders либо get orders

143:39

Speaker A

pass paramet id. Потом описываем все виды параметров. Это параметры, являющиеся частью пути для обращения к данным конкретным сущностям. Quy параметры - это параметры для фильтрации или управления погинацией. В заголовке хедерсы - это служебная или метаинформация в заголовках тело

143:59

Speaker A

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

144:11

Speaker A

String, integer, buля - это объект или массив. Указываем форматы, date, email и другие. Указываем обязательность, какие поля являются обязательными. Указываем примеры, как выглядят корректно заполненные поля для каждого параметра.

144:26

Speaker A

Дальше описываем валидацию входных параметров, критерии проверки корректности входных данных, например, чтобы дата создания заказа не могла быть в прошедшем времени и так далее. Потом переходим к описанию всех возможных ответов и ошибок. Чаще всего вариант успешного ответа один, а ошибочных

144:43

Speaker A

несколько. Дальше переходим к описанию всех возможных ответов и ошибок. Разработчик должен чётко понимать, что система вернёт в любом случае: и при успехе, и при ошибке. Чаще всего вариант успешного ответа один, а ошибочных несколько. Что мы описываем? Мы описываем успешные ответы. Это двухсотые

145:01

Speaker A

ответы. Мы описываем ошибочный ответ - это четырёхсотые, 401, 404, 403. Описываем пятисотые ошибки, например, 500. Сервис недоступен. Сейчас я приведу пример полноценного, подробного описания контракта интеграции. Также сможете его найти в текстовой версии урока. Что мы описываем, когда работаем с кавкой? В

145:22

Speaker A

первую очередь топик. Название топика, в котором публикуется события. Потом описываем схему сообщения. Так же как и для рыста, мы детально описываем все поля, их типы, форматы, обязательность, примеры. Также для этого часто используется GSON схема. Главное, что нужно запомнить, неважно, какую

145:38

Speaker A

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

145:58

Speaker A

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

146:17

Speaker A

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

146:35

Speaker A

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

146:54

Speaker A

этих развилок. Также не забываем про ошибки. Где и когда могут возникать ошибки, что система должна делать?

147:01

Speaker A

Ретраить, возвращать ответ, какой код ошибки должен быть, какой текст. И завершение. Что именно возвращается инициатору? Хорошие практики описание алгоритма. Во-первых, описывать всегда, даже если процесс кажется простым, иначе разработчики могут трактовать процесс по-разному. Во-вторых, одна sequнсдиаграмма на один endpint или

147:21

Speaker A

топик. Не сваливать несколько сценариев в одну схему, указывать и тление, альтернативные сценарии. Что происходит в случае успеха и в случае ошибки?

147:30

Speaker A

Декомпозировать. Если внутри одного вызывается 10 сервисов, куча логики, лучше вынести эти блоки отдельно. Также хорошей практикой является указывать и мпотентность и ретраи прямо в алгоритме.

147:44

Speaker A

Следует версионировать алгоритмы вместе с контрактом. Первая версия, вторая версия и так далее. Привязывать к бизнес-правилам, описывать, где именно применяется логика. Например, если сумма больше тысячи, то отправить уведомление о заказе, если меньше, то не надо. Ну и, конечно, не забывать про асинхронное

148:01

Speaker A

взаимодействие. В алгоритме писать, что событие отправлено в Кавку и далее обрабатывается другим сервисом и указать, что это за сервис или набор сервиса. В итоге контракт даёт разработчику, что на вход, что на выход, а алгоритм Sequenceс диаграмма даёт понимание, что происходит внутри и какие

148:18

Speaker A

шаги выполняются. Вместе эти два артефакта снимают 90% вопросов у разработчиков и делают интеграцию однозначной. Приведу пример описания процесса. Rest and point создание заказа post orders алгоритм шагов триггер клиент отправляет post orders с телом заказа севиice order service валидирует

148:39

Speaker A

токен обращается ксевиice далее записывается заказ в базу данных orders также тут есть альтернативный сценарий если BD недоступно то возвращаем ошибку 500 и второй альтернативный сценарий если такой заказ есть то возвращаем ошибку 409 далее публикуем события в кафку для последующей обработки сервиса

148:58

Speaker A

складов и доставки. Потом возвращаем клиенту 2011 created с ID заказа и его статуса. Какие могут возникнуть ошибки?

149:07

Speaker A

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

149:30

Speaker A

учесть, какие контракты данных стоит использовать. Пятый шаг в нашем проектировании - это работа с данными.

149:36

Speaker A

Первая и самая важная задача - подобрать правильный инструмент для хранения, обработки данных. Выбор зависит от конкретной задачи, нагрузки, стандартов, принятых компаний. Здесь мы ориентируемся на сценарии использования и технологические стек компании. Давайте теперь разберём типы задач, подходящие технологии и их ключевые свойства.

149:55

Speaker A

Первый пример - это транзакционные операции, покупки, работа с балансами, остатками. Подходят технологии реляционные СУBD, SQL, то есть Postg SQL, MySQL. И ключевые свойства - это оси транзакции, надёжность, строгость систем, консистентность данных.

150:09

Speaker A

Следующий тип задач - это кэширование, то есть ускорение доступа к часто запрашиваемым данным. Тут подойдёт технологияри кэша или соответственно, какие свойства у этих систем - это высочайшая скорость чтения хранения данных в оперативной памяти для быстрого к ним доступа. Следующий тип задач -

150:25

Speaker A

высоконагруженная аналитика, то есть обработка больших объёмов данных. Подходят колоночные с УПД, например, Клиck House. Из их свойств - это сверхбыстроаналитические запросы и оптимизация для чтения. Ну и разберём следующий кейс хранения документов, то есть с гибкой структурой, например, там

150:40

Speaker A

профили пользователя. И, соответственно, тут подходит документно ориентированные с УПД, например, Mongo DB. И какие должны быть свойства? Гибкость системой контрактов и хорошее горизонтальное масштабирование. Вы как аналитик должны проанализировать потребности и предложить наиболее подходящий тип хранилища. Хорошая практика: не стоит

150:58

Speaker A

брать экзотическую СУПД, если в компании нет экспертизы для её поддержки. Хорошие практики проектирования данных. Сначала идёт логическая модель, потом физическая. Не прыгать сразу с УПД.

151:10

Speaker A

Нормализация хотя бы до третьего уровня. Убрать дупли, но не усложнять. Денормализация только при необходимости, например, при высоких нагрузках.

151:18

Speaker A

Фиксировать бизнес ограничения не только в коде, но и в БД. Например, уникальности имейла в виде поля UN в BD.

151:26

Speaker A

Не допускать общий БD для большого количества сервисов в микросервисной архитектуре. Хорошо, когда у каждого сервиса своя база. Логическая модель данных - это бизнес-уровень. Мы описываем сущности, их поля и связи между ними без деталей конкретной СПД.

151:42

Speaker A

Пример: сущность: пользователь, юзер, поля: ID, имя, email, дата регистрации, сущность заказ, ордер, поля: ID, дата, сумма, статус, связь. У одного пользователя может быть много заказов, но у одного заказа может быть только один пользователь, то есть один ко многому. С помощью какого артефакта мы

152:01

Speaker A

это показываем? Ярдиаграмма с сущностями, атрибутами и связями между ними. Один: од, один ко многому и многое кому. Теперь разберём физическую модель данных. Это уже технический уровень, привязанный к конкретной спD. Здесь важно указать типы данных. Big integer против интеджера, uit против warрчара.

152:20

Speaker A

Прописать ограничения. Not now, unque. Учесть индексы. Поиск по имейлу. Значит, вешаем индекс на поле email. учесть максимальные размеры, например, Warchar 50 для названия товара. Хорошая практика - это общаться с бизнесом и уточнять реальные ограничения полей, параметров, например, длину названия товара,

152:40

Speaker A

описание товара и так далее, транзакционные свойства. Если система связана с балансами, заказами или остатками, то мы проектируем интеграции, описываем, какие таблицы участвуют, какие шаги атомарные, то есть либо выполняется всё, либо откатывается к изначальному состоянию. Выбираем уровень изоляции транзакции. Например, при

153:02

Speaker A

создании заказа создаётся запись в таблице orders, списываются остатки в таблице Stocks, фиксируется транзакция в таблице Payments. Все шаги должны быть либо успешными, либо откатиться, то есть сделать ролбэк.

153:20

Speaker A

Теперь перейдём, наверное, к самому важному и интересному вопросу. Как всё это выглядит на собеседованиях? Задания и вопросы можно условно поделить на две большие группы. теоретические и практические. Популярны группы теоретических вопросов. Цель этих вопросов - проверить глубину ваших знаний на понимание, почему та или иная

153:40

Speaker A

технология или подход были выбраны. Вы должны не просто знать определения, а понимать тонкости, плюсы и минусы каждого решения. Первая группа вопросов - это брокеры сообщений. Например, в чём принципиальная разница между Кавкой и Rabit MQ? Тут проверяет понимание разницы между потоковой обработкой

153:57

Speaker A

событий и очередями сообщений. Вторая популярная группа вопросов про интеграции. Синхронные против асинхронных интеграций. Приведите примеры, когда вы выберете тот или иной подход. Какие есть виды интеграции? Rest против GRPC, Rest против SUAP, когда лучше что использовать. Следующая группа вопросов - это про архитектурные стили.

154:17

Speaker A

Назовите плюсы и минусы микросервисов и монолитов. В каком случае вы бы порекомендовали не использовать микросервисы? Следующая группа вопросов про масштабирование сервисов.

154:27

Speaker A

Горизонтальная против вертикального масштабирования. В чём разница? Что такое балансировщик нагрузки, зачем он нужен? Масштабирование базданных, что такое репликация, партиционирование, шардирование, какую проблему решает каждый из этих подходов. Также любят спрашивать про основы базданных.

154:44

Speaker A

Например, расшифруйте принципы ASIT. В чём ключевая разница между SQL и NO SQL базами данных? Приведите примеры использования для каждого типа BD. Ну и, конечно, поговорим про типовые практические задачи. Цель этих задач- посмотреть, как вы мыслите, в условиях, приближенным к реальным. Здесь

155:01

Speaker A

оценивается не только финальный правильный ответ, сколько ваш подход, умение задавать уточняющие вопросы, начинать с требований и обосновывать свои решения. Примеры задач. Конечно же, это проектирование данных. Нарисуйте ярдиаграмму для сервиса аренды самокатов, либо каршеринга, либо системы бронирования отелей. Задачи на оценку

155:22

Speaker A

нагрузки. Давайте рассчитаем примерную нагрузку и объём базы данных для сервиса сокращения ссылок типа Bitли на 10 млн пользователей. Конечно, это задача по всеми любимому проектированию Апии.

155:33

Speaker A

Спроектируйте апии, опишите набор методов АИ, опишите каждый endpint, опишите модели запросов, ответов для процесса создания заказа в интернет-магазине. Задача на архитектуру верхнего уровня. Нарисуйте карту архитектуры для системы онлайн-голосования либо простого аналога Instagram и задачи на детализацию интеграции. Нарисуйте sequнс диаграмму

155:54

Speaker A

для процесса онлайнзаказа еды или процесса выдачи кредитной карты в банке. Как видите, это те самые практические задачи, которые мы разбирали в предыдущих модулях. Умение быстро и уверенно выполнять их на собеседовании прямой показатель вашего Cenorровня. Я приложил популярные задачи и их

156:11

Speaker A

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

156:30

Speaker A

теоретическая база, давайте перейдём к самому главному, к практике. Я вам дам небольшое, но очень важное домашнее задание. В чём оно заключается? Вот ваш план действий, практические шаги. Если вы уже работаете аналитиком, то у вас есть две возможные развилки в

156:44

Speaker A

зависимости от ситуации в вашей компании. Если у вас в компании проблемы с документацией, процессы и документации не описаны, описаны плохо или вообще всё отсутствует, то поздравляю, у вас идеальные обстоятельства для тренировки.

156:59

Speaker A

Вот что стоит сделать. Сначала возьмите на себя инициативу и опишите ваши системы, используя модель C4, первый и второй уровень. Далее опишите ключевые технические процессы. Выберите несколько самых важных бизнес-процессов и задокументируйте их с точки зрения системного взаимодействия. Это тот

157:19

Speaker A

жезкейс, но на уровне алгоритмов и sequнс диаграмм, которые мы обсуждали ранее. Далее опишите, задокументируйте несколько ключевых эндпоинтов по той структуре, что мы ранее разбирали, то есть описать контракт и описать алгоритм. И, конечно же, попросите ревью. Обязательно покажите результат

157:36

Speaker A

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

157:54

Speaker A

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

158:12

Speaker A

задачу. Обратитесь к вашему менеджеру или техледу с просьбой дать вам небольшую некритичную задачу на проектирование новой доработки. Конечно же, с последующим ревью от старших коллег. Если вы не работаете или хотите подготовиться к собеседованиям, то я приложу к этому уроку несколько типовых

158:28

Speaker A

задач по системному дизайну для аналитиков с их подробными разборами. Попробуйте сначала решить их самостоятельно. Нарисуйте схемы, опишите контракты, рассчитайте нагрузку и размер БД, а уже потом сверьтесь с моим решением. Это самые полезные советы, которые позволят вам не просто

158:44

Speaker A

прослушать курс, а уже сегодня начать что-то делать и двигаться в правильном направлении. Главное, не останавливайтесь и применяйте знания на практике. Успехов.

158:57

Speaker A

Привет. Меня зовут Сергей Филичкин. Я ментор и Python backend разработчик с опытом работы от мелких компаний, где к системному дизайну относятся совершенно халатно. До работы в крупных компаниях с десятками тысяч сотрудников, где без хорошо построенной системы компания может понести убытки в миллионы, а то и

159:17

Speaker A

в миллиарды рублей. И сразу стоит понять, что системный дизайн для бэкэнд-разработчиков - это не просто какая-то теория из учебников или из статей или из видосов на Ютубе. Это крайне важный практический навык, от которого реально зависит масштабируемость, надёжность и

159:32

Speaker A

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

159:51

Speaker A

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

160:06

Speaker A

Итак, в первой части мы разберём, какие есть зоны ответственности у разработчика в системном дизайне, что от вас ожидают на собеседовании, какие типовые задачи дают и что примерно нужно на них отвечать и что именно оценивают интервьеры, а также какие архитектурные

160:21

Speaker A

паттерны нужно держать в голове. Итак, давайте рассмотрим, за что всё-таки отвечают бэкэнд-разработчики, и коротко рассмотрим зоны ответственности. Первое - это архитектура и управление данными.

160:31

Speaker A

Эээкэнд-разработчик отвечает за то, как спроектировать базу данных, как её сделать согласованной, масштабируемой, чтобы она впоследствии выдерживала нагрузку от десятков до сотен и миллионов записей в этой базе данных.

160:43

Speaker A

Сюда также может входить оптимизация запросов, выбор между SQL и N SQL базами данных, а, построение индексов и выбор стратегии миграции. Чтобы понять, о чём эта зона, вы можете задать себе вопрос: что будет, если база внезапно упадёт, и это вам поможет точнее спроектировать

161:00

Speaker A

систему? Следующая зона - это проектирование и интеграция API. Вы проектируете, как сервисы между собой взаимодействуют, Rest, графки PI или другими способами. Обязательно следите, чтобы новые версии не ломали старые клиенты, и обрабатываете сторонние ошибки от серверов. В целом здесь можно

161:18

Speaker A

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

161:34

Speaker A

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

161:46

Speaker A

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

162:01

Speaker A

применился эффект или нет. И дальше это, конечно, инфраструктура и производительность. Покн разработчики проектируют систему под большую нагрузку, обеспечивают надёжность. Вы внедряете коширование для ускорения откликов, проектируете шардинг, репликацию. Также здесь можно добавить мониторинг для раннего отва ошибок или CCD процесс. По сути, это будет вашей

162:21

Speaker A

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

162:38

Speaker A

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

162:53

Speaker A

времени и ресурсов, особенно на высокие позиции, там midle plus, синер. И в целом, чем выше грейд разработчика, тем большая часть вопросов будет направлена, как правило, на систему дизайн. Теперь давайте поговорим, что от вас всё-таки ожидают на собеседовании. Обычно этот

163:08

Speaker A

процесс происходит из нескольких этапов, но акцент делается на тех областях, где ээнд-разработчик приносит наибольшую пользу. Как правило, это работа с данными, масштабируемость и надёжность.

163:19

Speaker A

Обычно процесс интервью проходит так. Первое - это вы получаете задачу, например, спроектировать какую-нибудь социальную сеть или там условно сервис такси. И при получении такой задачи вам крайне важно в первую очередь задать уточняющие вопросы по этой системе. Эти вопросы могут быть, например, какой

163:35

Speaker A

объём данных ожидается, какие требования, консистентность SL и так далее. Это важнейший этап, потому что это покажет, что вы на всю систему смотрите комплексно, а не пытаетесь бежать, реализовать непонятно что, непонятно зачем и непонятно для кого.

163:51

Speaker A

Дальше ваша задача- проектировать систему. То есть сначала вы рисуете общую схему, тем делаете акцент на бэкэнде, то есть это взаимодействие сервисов, хранение данных, отказоустойчивость модель согласованности и так далее. Здесь самое важное - это идти от общего к частному и

164:07

Speaker A

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

164:25

Speaker A

выдерживать всплески нагрузки. Ну и в конце могут быть какие-то уточнения по типу безопасности, эксплуатации, альтернативных подходов. То есть, например, почему выбрали SQL, а не N SQL, а как будет работать аудит и что будет в целом с логированием в вашей

164:40

Speaker A

системе. То есть здесь интервьюеру важно увидеть, что вы не просто знаете инструменты, а умеете рассуждать и объяснять свои решения. При проектировании архитектуры обращайте внимание на следующие элементы. Первое - это потоки данных, то есть что, как, куда и зачем движется. Дальше, конечно

164:57

Speaker A

же, нужно обозначить границы сервисом, а правильно декомпозировать на монолит и микросервисную архитектуру. И, конечно, важно выбрать правильно структуру базы данных. То есть это может быть SQL, No SQL, графовые, Time Series, поисковые и так далее. Здесь главное выбрать именно

165:15

Speaker A

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

165:31

Speaker A

сказал, не забыть про надёжность и безопасность. То есть вы должны чётко понять, что выбрать: Монолит или микросервис. Ваша задача здесь найти баланс именно в вашем конкретном случае, выбрать между простотой и гибкостью.

165:43

Speaker A

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

165:59

Speaker A

нужно выбирать под вашу задачу. в блоке про безопасность не забывайте говорить про аутентификацию, авторизацию, шифрование и в целом защиту от атак и нормальное логирование с аудитом. Ну и в блоке про надёжность - это, конечно, ретрай, это circuitбреaker, heckки и так

166:16

Speaker A

далее. То есть всё это нужно, чтобы ваша система не падала при первом же сбое. Ну а резервирование и Disaster Recovery просто поможет вам быстро восстановиться, если всё-таки что-то пойдёт не так. На самом собеседовании часто дают типовые задачки, которые я бы

166:30

Speaker A

настоятельно рекомендовал вам разобрать заранее. Некоторыми примерами это может быть, например, URL Shortner, то есть проектирование сервиса, сокращение ссылок с многомиллионными записями, с кашированием, шардированием и, возможно, репликацией и аналитикой. Могут попросить реализовать чат, то есть это realта коммуникации, а доставка

166:50

Speaker A

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

167:09

Speaker A

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

167:24

Speaker A

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

167:42

Speaker A

Как пример, можно рассмотреть супер простую схему сокращателя ссылок. А здесь важный момент, что не всегда ваша система должна использовать 30 компонентов, там, 10 микросервисов, пять баз данных и так далее. Вам важно нарисовать именно ту схему, которая подходит под конкретно вашу задачу. Но

167:59

Speaker A

если вам всё-таки сказали, что ваша система должна выдерживать миллионы записей, то схема могла бы выглядеть примерно так. По сути, здесь пользователь просто отправляет запрос на фронте, где может быть NextJS или React.

168:11

Speaker A

Там, в принципе, без разницы, что там будет. А дальше это API Gateway или Old Bouncer, то есть они будут балансировать нагрузку между Baкэнд-сервисами.

168:21

Speaker A

А дальше уже будет наш, который может быть написан в целом на чём угодно, там Fast API, Jango, Noj, другие языки программирования, без разницы. Дальше это несколько сервисов. То есть один, например, создаёт короткую ссылку и сохраняет соответствие этих ссылок. А

168:36

Speaker A

дальше у нас будет, например, отдельный Redirect сервис. Это который по ссылке делает редирект на оригинал. и сервис аналитики, который просто собирает аналитику кликов. Конечно же, нам здесь потребуются базы данных. Это, например, Postgress или там MSQL, Redis. Даже мы

168:52

Speaker A

можем вставить и брокер сообщений, ну, и подвязать к этому какую-то аналитику, мониторинг и так далее. Если вы уже сможете чётко объяснить, зачем здесь нужен каждый компонент, интервьюеру уже может быть этого достаточно. Как я уже говорил, интервьеру не обязательно

169:06

Speaker A

реализовывать очень сложную схему. Чаще всего интерьер будет обращать внимание на другие пункты. То есть первое - это системное мышление. Видите ли вы общую картину, как компоненты взаимодействуют между собой? Думаете ли вы про сбой и крайние случаи? Дальше это моделирование

169:23

Speaker A

данных. То есть, умеете ли вы проектировать базу данных? Выбираете подходящие типы баз, а можете ли вы объяснить шардирование? Конечно же, стоит отметить про масштабирование. То есть, знаете ли вы типичные узкие места в подобных схемах и умеете ли вы

169:36

Speaker A

проектировать горизонтально масштабируемое решение? Ну и, конечно, практичность. Умеете ли вы обосновывать выбор технологии и учитываете ли вы эксплуатационные риски? Ну и если резюмировать, то как готовиться к собеседованию и на что стоит обратить внимание? То есть в первую очередь,

169:51

Speaker A

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

170:10

Speaker A

обсуждайте трейдофы. Ну и отсылаюсь немножко к предыдущему пункту, то есть не торопитесь сразу погружаться в детали. Опять же обсудите сначала всё заранее. Не игнорируйте нефункциональные требования и не придумывайте то, что не нужно этой системе прямо сейчас.

170:31

Speaker A

Теперь давайте поговорим про масштабирование. То есть для бэкэнда разработчика понятие масштабирование выходит далеко за рамки. Там просто накинем железо и всё станет работать по мере увеличения пользователей. Важно проектировать системы так, чтобы они оставались стабильными, предсказуемыми и управляемыми с повышением нагрузки. То

170:50

Speaker A

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

171:06

Speaker A

память, увеличиваем количество памяти, ну и так далее. Такой подход может хорошо подойти для монолитов или для баз данных, которые сложно разделить, но здесь важно понимать, что железо мы не можем бесконечно улучшать. Второй вариант - это горизонтальное масштабирование. То есть это когда мы

171:21

Speaker A

просто добавляем новые узлы, это могут быть новые серверы, контейнеры, а, ну и так далее. То есть это уже ключевой подход для распределённых систем в современном мире. Чаще всего такой подход используется с балансировщиком нагрузки, с распределёнными базами данных и с очередями сообщений. Ну и

171:39

Speaker A

можно дополнительно отметить, это некое эластичное масштабирование. То есть это когда сама система понимает, что нужно добавить мощностей.

171:48

Speaker A

когда нагрузки стало больше и уменьшит, когда нагрузки стало меньше. Типичными примерами здесь может быть облака от Амазона либо решение от Кубернейса.

171:57

Speaker A

Главное помнить, что у облаков есть так называемый кодстарт и расширение будет происходить немгновенно. Ну а теперь давайте поговорим, что реально применяется в продакшене. Ну и первое - это, конечно, шардинг- это когда мы разделяем данные по разным базам или

172:11

Speaker A

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

172:27

Speaker A

копируем данные на несколько узлов. Здесь примерами может быть маерв, то есть это когда один узел принимает записи, а другие просто читают этот мастер. Или, например, мультимастер, когда несколько узлов могут принимать записи, но здесь гораздо сложнее обеспечить согласованность. Следующий

172:43

Speaker A

частый подход - это, конечно же, Evвен Driving, архитектура и очереди сообщений. Здесь, например, Rabbit, MQ, Кавка и другие брокеры позволяют не ждать синхронных ответов и помогают разгружать систему. То есть энд просто поставил задачу фон, ушёл делать какие-то свои задачи и дальше эта

173:02

Speaker A

задача, которую мы поставили очередь, обрабатывается асинхронно. Благодаря этому повышается устойчивость, и это позволяет нам масштабировать отдельные компоненты по мере необходимости.

173:11

Speaker A

Следующее - это SQRS и Even Sorum. SQRS, то есть это Command Query Responsibility segregation, разделяет команды, например, на чтение и запись. И такой подход позволяет оптимизировать разные части системы под конкретные сценарии.

173:26

Speaker A

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

173:43

Speaker A

приложения через какие-нибудь библиотеки или там, например, через readyс или же использовать распределённые хранилища, например, тот же Redis clustter, ну или же CDN для статики и API ответов. Ну для того, чтобы использовать эти инструменты бэкэнд-разработчику критически важно понимать, что именно

174:00

Speaker A

может стать узким местом. Если коротко рассмотреть, это, например, могут быть CPU bound задачи, то есть это когда по сути вам нужны вычислительные мощности.

174:08

Speaker A

Ну, например, там шифрование, машинное обучение и так далее. Решением здесь может быть, например, распределение на отдельные ворки узуи, на параллелизм или на асинхронность. Memory bound - это когда у вас хранятся большие объёмы данных в оперативной памяти. Решением здесь может быть просто оптимизация

174:25

Speaker A

структур данных, ну или распределённое кэширование. А её баoунд задачи - это когда происходят ожидание с диска, с базы данных или, может быть, от другого микросервиса. Часто здесь решением тоже может быть асинхронный input output, а батчинг, кэширование, ну или

174:40

Speaker A

использование очередей сообщений и network bound, то есть это когда ограничение по пропускной способности вашей сети. Решением же здесь может быть сжатие данных, использование GRPC вместо REST или, например, использование CDN для статических ресурсов. Итак, давайте предположим, что вы всё сделали,

174:57

Speaker A

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

175:13

Speaker A

всегда компромисс. Не на всё может пойти бизнес, но вы как минимум должны об этом знать. И желательно это проговорить с интерьером. Первый немножко радикальный подход - это graceful degradation, то есть постепенное ухудшение. То есть это когда вы по мере роста нагрузки можете

175:27

Speaker A

какие-то компоненты постепенно отключать. Ну, например, там лента рекомендаций, например, временно не работает, но бронирования продолжают работать. Это немножко радикальный подход. Бизнес может на такое не пойти, но вы должны знать о существовании такого подхода. Второй - это рейдлимитинг иг, то есть когда мы просто

175:44

Speaker A

ограничиваем число запросов на конкретного пользователя. Следующее - это бэкпрешер. По сути, это механизм, который сообщает системе или клиенту или продюсеру, что он просто не может принять больше данных. Ещё один подход - это circuit breaker, то есть это когда

176:00

Speaker A

сервис временно становится недоступен, то есть мы как бы временно разрываем цепь, а чтобы не заспамить его новыми запросами. Следующее - это balk headad pattern, то есть это мы разделяем ресурсы, и сбой одного компонента не может уронить всю систему целиком.

176:15

Speaker A

Например, мы здесь можем выделить отдельные воркерпулы под разные типы задач. Ну и, кстати, многих этих вещей можно было бы избежать, если бы у вас была заложена obserсервабиility, то есть наблюдаемый за системой. И многие вещи вы могли бы превентивно увидеть и

176:30

Speaker A

пофиксить уже заранее. Зачем мы могли бы наблюдать чтобы быстрее обнаруживать проблемы, которые могут возникать? А вот несколько ключевых параметров. Первое - это letcy, то есть, по сути, время ответа. Мы можем наблюдать за тем, насколько быстро отвечают наши опишки, и

176:46

Speaker A

своевременно предпринимать какие-нибудь необходимые действия потому, чтобы ускорить ответ от конкретной опишки. Следующее - это, то есть это, по сути, количество запросов в секунду. А если мы знаем, как у нас растёт нагрузка, какие у нас бывают пиковые нагрузки, то мы

177:01

Speaker A

можем увидеть повышающуюся нагрузку и предпринять какие-нибудь необходимые меры по укреплению этого узла, чтобы он выдерживал последующие всплески нашей нагрузки. Также можно следить за эр erроррейтом, то есть мы просто видим, в каких элементах системы чаще всего возникают ошибки, и опять же мы можем

177:19

Speaker A

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

177:34

Speaker A

обнаружите. Ну и следующее - это resуization и saturation, то есть это загрузка CPU, памяти, дисков, сети, а и насколько ваши ресурсы близки к максимальной нагрузке. Для этого часто используются специализированные инструменты, например, Прометеус плюс графана. Open Telemetry, Ecгerвки, ну и так далее. Подробно про них здесь

177:58

Speaker A

мы говорить не будем, но в комплексных системах они обязательно должны присутствовать. Ну, ещё раз, масштабирование - это не про то, чтобы просто добавить пару серверов, когда вырастет нагрузка. Это про то, чтобы спроектировать систему так, чтобы она выдержала рост ваших пользователей,

178:13

Speaker A

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

178:28

Speaker A

проблемы ещё до того, как они уже случатся. И сейчас давайте поговорим про распределение нагрузки. Когда мы говорим про масштабируемые системы, первым делом встаёт вопрос, как распределить миллионы запросов так, чтобы система всё это выдержала, обработала и отдала корректные ответы. Итак, давайте

178:50

Speaker A

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

179:04

Speaker A

То есть, если с одним сервером у нас что-то не так, то трафик просто перераспределяется на другие серверы.

179:10

Speaker A

Также это может помочь нам с плавным деплоем, то есть можем направлять часть трафика на новую версию системы, а часть пока что на старую. Это ещё называется канареечным развёртыванием. Также, конечно же, он может помочь нам оптимизировать нагрузку. То есть у нас

179:24

Speaker A

могут быть разные сервера по мощности, и более мощным серверам может доставаться больше трафика, чем менее мощно. Ну и, конечно, делает нашу архитектуру более гибкой. То есть мы можем просто на Литу добавлять сервера, и трафик на них уже начнёт своевременно распределяться. Ещё

179:39

Speaker A

было бы полезно знать, что современные балансировщики работают на разных уровнях стека. Нас больше всего интересуют L4 и L7. L4 - это, по сути, транспортный слой, когда решения принимаются на уровне IP и портов. Это самый простой способ, но здесь минус в

179:56

Speaker A

том, что он не знает, что находится внутри запроса. И такой подход может подойти для TCP, UDP сервисов. И L7 - это уровень приложения, когда данные анализируются на прикладном уровне, то есть это HTTP заголовки, URL пути, кукисы и так далее. Это нам может

180:14

Speaker A

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

180:29

Speaker A

пользователей, то есть они могут принимать на себя удары досов, а, завершать SSL-сеи часто интегрироваться в CD. И внутренние балансировщики, они уже работают внутри сервисов, то есть они распределяют трафик между вашими микросервисами и работают с минимальной задержкой, поддерживают GRPC и Rest, как

180:49

Speaker A

правило. Ну, есть ещё балансировщики баз данных. Это, по сути, отдельная категория. Они решают задачу разделения запросов, они могут учитывать наличие мастер и реплик, ну и могут заодно обеспечивать согласованность данных.

181:03

Speaker A

Давайте ещё коротко проговорим, какие бывают виды балансировки, потому что даже такой вопрос иногда могут задавать на собеседованиях. Первое - это Roundro Robin, то есть это просто циклическая раздача запросов. А хорошо может подойти для statless приложений. А по сути

181:17

Speaker A

запросы здесь просто ходят кругами. И таким образом распределяется нагрузка. Следующее - это немножко улучшенная версия- это Weighted Round Robin. То есть этот алгоритм по сути учитывает мощности сервера и более мощным серверам достаются больше нагрузки. Есть ещё подход List connections, то есть это

181:35

Speaker A

когда запрос отправляется серверу, у которого наименьшее количество активных соединений. Часто такое может подойти для API с непредсказуемой нагрузкой. У этого алгоритма тоже есть немножко улучшенная версия Weighted List Connections, то есть она также учитывает мощности сервера, и более мощным

181:53

Speaker A

серверам достаётся больше нагрузки. Ну, конечно же, ещё учитывается текущая загруженность сервера. Также есть алгоритм Response Time Based, то есть здесь просто учитывается выбор сервера по минимальной задержке. Ну и consistent hasшиing полезен для кэширования и шардирования. Это когда один и тот же

182:11

Speaker A

пользователь всегда попадает на один и тот же сервер. Но здесь может возникнуть вопрос: а как же быть с сессиями? Здесь тоже есть несколько подходов, которые было бы полезно знать. Первое - это Session Affinity. Это, по сути, липкие сессии, когда пользователь закрепляется

182:26

Speaker A

за определённым сервером. Довольно простое решение, но оно плохо масштабируется. Следующее - это Cookie Based Affinity. Это когда сервер помечает пользователя через cookie. Ещё один подход - это IPAS Affinity. Ну, я думаю, здесь из названия можно догадаться. Это когда пользователь

182:43

Speaker A

просто закреплён по IP, но это может быть не надёжно, потому что у пользователя может быть несколько айпишников. Хорошего решение может быть просто вынести во внешнее хранилище там какой-нибудь редис или базу данных. А, то есть здесь любой сервер может

182:58

Speaker A

обработать запрос и сессия хранится централизованно. Ну и ещё стоит у вас токены. Это там по сути GVT токен. Это когда информация о пользователе хранится прямо в токен. Итак, у нас может всё работать, но мы же не можем круглосуточно следить за тем, что отпал

183:14

Speaker A

у нас сервер, не отпал, в каком статусе. А для этого есть несколько вариантов проверок, которые балансировщик должен уметь использовать. Обычно это два подхода - это healthчеки и failover.

183:25

Speaker A

Healthки могут быть двух видов. То есть это active checks, когда сам отправляет тестовые запросы балансировщик. И passive checks - это когда анализируются реальные запросы от пользователей и на основании этих данных принимаются какие-то решения. И если сервер не отвечает, то здесь как раз включается

183:43

Speaker A

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

184:03

Speaker A

более продвинутые подходы. Например, это сервис Discovery. Это когда сервис сам регистрируется и сам же снимается с регистрацией. Следующее - это Health Aware Discovery. Это когда маршрутизация происходит только на те сервисы, которые гарантированно работают. Следующий подход - это TRF сплитинг либо

184:21

Speaker A

канареечное развёртывание. Это когда мы на новую версию сервиса даём сначала 1% трафика, потом 10, потом может быть 20-3050. И так мы доходим до 100%. И есть ещё подход фичефлагов - это когда мы часть функционала закрываем за фичифлагом и некоторые пользователи

184:39

Speaker A

могут увидеть новую фичу, а некоторые могут её не увидеть. Ну и мало того, что я здесь наговорил, мы ещё должны учесть, что наша система может работать в нескольких регионах, и мы ещё должны сделать географическую маршрутизацию.

184:52

Speaker A

Географическая маршрутизация может быть следующей. Первое - это letcy based rутин - это когда пользователь просто идёт в ближайший дата-центр. Второе - это геороутинг, когда маршрутизация происходит по геолокации, ну, по сути, по айпишникам. И Disaster Recovery - это когда аварийно переключается трафик с

185:10

Speaker A

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

185:24

Speaker A

Дальше это, конечно, выбрать правильную архитектуру приложения. Обязательно нужно выстроить грамотную работу с базой данных, учесть мониторинг и диагностику и интегрироваться с микросервисами и DevOps практиками. Итак, у нас осталась заключительная глава по системному дизайну в бэкэнд разработке. Это хранение данных.

185:46

Speaker A

Когда мы проектируем базы данных, мы обязательно должны учесть, какие характеристики для нас критически важны.

185:52

Speaker A

Мы обязательно должны обратить внимание на надёжность. То есть это когда наши данные надёжно хранятся и не теряются.

185:59

Speaker A

Даже в тех случаях, если у нас сервис упал, наши данные должны быть на месте.

186:03

Speaker A

Следующее - это доступность. Это когда наши данные доступны пользователю в любой момент времени. обязательно нужно подумать про масштабируемость, то есть когда наша система выдерживает рост количества пользователя и объёма данных.

186:15

Speaker A

Конечно же, производительность, то есть наши операции, записи, чтения должны выполняться максимально быстро, насколько это возможно. Ну и согласованность - это когда наши пользователи должны получать актуальные данные, хотя уровень согласованности здесь может быть разным. По сути, проектирование хранения систем данных

186:33

Speaker A

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

186:50

Speaker A

храниться, да? То есть это могут быть транзакции, логи какие-нибудь медиафайлы, аналитика и так далее.

186:55

Speaker A

Дальше нужно определить, кто потребляет эти данные. То есть это пользователи, какие-то сервисы, аналитики или ещё кто-нибудь. Ну и какие SL? SL - это се Agreement, то есть это соглашение об уровне сервиса. А какие нам здесь SL нужны? То есть это, например, может быть

187:12

Speaker A

99,9% доступности, а какая-то согласованность или определённое время отклика. Ну и здесь нужно помнить про каптеорему. Если вы с ней не знакомы, то рекомендую ознакомиться, но мы сейчас не будем на ней подробно останавливаться. Следующий шаг - это классифицировать наши данные,

187:29

Speaker A

то есть понять, какие они по структуре. Это структурированные таблицы, полустрактурированные там например какой-нибудь Jon. А или это вообще в целом неструктурированные данные по типу там видео и изображений? Понять, какие эти данные по времени жизни. То есть это горячие, которые постоянно используются,

187:46

Speaker A

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

188:00

Speaker A

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

188:16

Speaker A

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

188:32

Speaker A

данных у нас будет использоваться. Например, это может быть реляционная база данных, по сути тот самый SQL. Это могут быть некоторые Nesql базы данных, например документоориентированные либо база ключ значения, э, либо колоночная, графовая, ну, и так далее. Ну или мы

188:48

Speaker A

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

189:03

Speaker A

Для SQL мы можем рисовать диаграмму, для новый SQL какой-нибудь JON. Далее мы определяем ключи, например, primary K или Partition K. И здесь же можем запланировать сразу индексы. После этого мы можем перейти к шагу шесть - это спроектировать физическую схему. Здесь

189:19

Speaker A

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

189:35

Speaker A

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

189:47

Speaker A

Здесь также мы можем подумать про кэширование и учесть pre agгation данные. То есть это, по сути, заранее посчитанные данные. Ну и неплохо было бы подумать про партицирование. Это когда мы делим большую таблицу на некие части.

190:01

Speaker A

На восьмом шаге нам нужно подумать про отказоустойчивость и бэкапы. То есть мы думаем, какие у нас будут регулярные бэкапы. То есть полностью мы бэкап сохраняем или частично. Дальше думаем, что с георепликацией и как мы будем восстанавливаться после сбоев. Далее, на

190:16

Speaker A

девятом шаге мы должны настроить мониторинг нашей системы. То есть мы должны понимать время откликах запросов, сколько этих запросов и как растёт нагрузка на нашу базу данных. Конечно, хорошо настроить логин на какие-то медленные запросы или дедлоки и алерты на те моменты, когда у нас упала

190:36

Speaker A

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

190:52

Speaker A

схемы, политики с и так далее. Обязательно нужно проводить регулярные аудитсистемы и пересматривать стратегию по мере роста этой самой системы. Ну и несколько небольших советов по принципу Парета, а, внедрив которые, вы закроете 80% болей, которые у вас могут возникнуть. Первое - это, конечно, лучше

191:12

Speaker A

просто начать с одной базы. Это может быть постгрес, а по мере необходимости уже добавлять No SQL, добавлять кэш и так далее. Следующий совет - это всегда проектируйте копирование и восстановление данных. Это вас убережёт от кучи потраченных нервов. Обязательно

191:28

Speaker A

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

191:44

Speaker A

Ну и ещё раз, хранение данных - это всегда баланс между производительностью, согласованностью и масштабируемостью.

191:51

Speaker A

разработчику важно уметь выбирать правильное хранилище данных, уметь комбинировать SQL и Note SQL, проектировать репликацию, шардинг и кэширование. По сути, в этом и есть некое искусство между тем, чтобы отдавать данные максимально быстро и при этом хранить их максимально надёжно.

192:09

Speaker A

Главное, не пытайся понять всё и сразу. Тема довольно большая, обширная и вероятно сложная. А возвращайся к тем моментам по мере необходимости и изучай их поэтапно. Надеюсь, ты обязательно справишься с этой нелёгкой темой и спроектируешь такую систему, которая выдержит даже самые большие нагрузки.

192:33

Speaker A

Привет, меня зовут Автошенко Андрей. Я занимаю должность техледа фронт-команды компании Premere One и также являюсь ментором сообщества Frontend Alнс. В этой главе я расскажу о том, как системный дизайн применяется во фронтде, какие задачи он помогает решать и про

192:49

Speaker A

специфику собеседований для фронтнд разработчиков по систмдизайну. System дизайн часто является одним из последних этапов на собеседование фронт-разработчиков в крупных IT-компаниях. Обычно эта секция встречается на грейдах Middle Plus и Senore. На ней вам могут предложить как общую задачу вида "Давай спроектируем

193:06

Speaker A

YouTube", так и более прикладную задачу, привязанную к конкретной команде или продукту. Например, давай спроектируем чат между покупателем и продавцом в нашем продукте. Вопросы на интервью по систем-дизайну часто могут не иметь единственного правильного ответа, а процесс самого интервью может строиться

193:22

Speaker A

по-разному в зависимости от задачи, кандидата, интерьера и специфики продукта. Может возникнуть вопрос: а зачем вообще проводить эту секцию для фронт-разработчиков? Ведь в реальной работе редко, когда приходится строить систему с нуля или проектировать принципиально новые и сложные архитектуры. Честный ответ. Крупные

193:40

Speaker A

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

193:58

Speaker A

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

194:15

Speaker A

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

194:35

Speaker A

мониторинг ошибок и метрики. В самом начале собеседования вам могут дать либо скрин проектируемой системы, либо, что чаще, просто расскажут словами, что нужно будет спроектировать. Можно выделить три основных этапа собеседования: понимание поставленное задачи, построение высокоуровневого дизайна и погружения в детали. На

194:54

Speaker A

интервью вас могут попросить спроектировать стриминговый сервис, чат, приложения для букинга, marркетплейс, почтовые клиенты и многое другое. Чаще всего задача приближена к реальным продуктам компании. Так, например, часто в Авито дают спроектировать чат между покупателем и продавцом. Вбанке месengжер, в Яндексе сервис ответов и

195:14

Speaker A

вопросов. На секции дают задачу без чётких требований. Это нужно, чтобы вы сами задавали вопросы на понимание границ проектируемой системы, сценариев использования продукта и собрали функциональные и нефункциональные требования. От вас ожидают, что вы зададите эти вопросы и учтёте собранную

195:31

Speaker A

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

195:54

Speaker A

системного дизайна на примере проектирования ленты социальной сети, аналог Твиттера или Фейсбука. Давайте начнём с разбора функциональных и нефункциональных требований.

196:03

Speaker A

Функциональные требования. Пользователь может просматривать как свои посты, так и посты других пользователей. Пользователь может создать новый пост, содержащий текст или изображение.

196:13

Speaker A

Пользователь может ставить реакции на пост. У нас должна быть поддержка мобильных устройств, но при этом поддержка очень таргет браузеров не требуется. К нефункциональным требованиям относится, что система должна поддерживать до 100.000 пользователей онлайн одновременно. Лента должна загружаться менее чем за 2

196:31

Speaker A

секунды при стабильном интернет-соединении. У нас должна быть высокая доступность сервиса и возможность пользоваться сервисом людям с ограниченными возможностями. Из нефункциональных требований нас, как фронтендеров, в большей части интересуют пункты 2 ичетыре. Остальное решается зачастую силами бэкэнда и девопса. После

196:50

Speaker A

того, как вы собрали требования и уточнили границы системы, наступает этап высокоуровневого дизайна. Первое, что вас могут попросить - это нарисовать UIUX дизайн, простой макет или блоксхему интерфейса. Сейчас вы видите пример такого макета. Сверху у нас есть навигация с кнопкой создания поста, и

197:08

Speaker A

ниже идёт лента самих постов с картинкой, текстом и различными кнопками. Дальше имеет смысл перейти к дереву компонентов и связях между ними.

197:16

Speaker A

Здесь нужно отобразить основные компоненты, их взаимодействие и обмен данными через выбранный нами state-менеджер или иной механизм. Наш фронтовый проект начинается с корневого компонента app. Далее у нас идёт основной компонент fit, который будет отвечать за новостную ленту. Он состоит

197:33

Speaker A

из двух компонентов: навигация и постов. Компонент пост - это список наших постов, где сам компонентпост состоит из картинки, текста и кнопки реакций.

197:44

Speaker A

Внутри навигации у нас есть кнопка создания поста. Она состоит из текстового редактора, кнопки для загрузки картинки и кнопки для отправки.

197:54

Speaker A

Общение с бэкэндом будет проходить через AP клиент. Тут может быть как самописное решение, так и готовая библиотека, например, там query. Также мы отразили на схеме наш redк store, в котором будет храниться написанный, но ещё не отправленный пост, чтобы иметь

198:09

Speaker A

возможность сохранить его в случае перезагрузки страницы или закрытия вкладки. Несмотря на то, что вы фронтенд-разработчик, от вас будет требовать высокоуровнего дизайна всей системы целиком, не только клиентской части, но и серверной. Обычно в схему включают сервера приложений, балансеры, кэш, БF, хранилище данных и очереди. Мы

198:29

Speaker A

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

198:36

Speaker A

Здесь мы можем увидеть сервис постов, сервис ФИДАA, севис usеer и servвиice relation, который в будущем будет отвечать за логику подписок на ленту других пользователей. Ещё один частый элемент на интервью - это расчёт целевой нагрузки на ээкэнд. Это помогает понять,

198:51

Speaker A

удовлетворяет ли наш спроектированный дизайн собранным требованиям. Но часто на фронтендсобеседованиях этот этап опускают. Для полноты картины давайте проведём такой расчёт, не сильно погружаясь в детали. Из требований предположим, что количество уникальных пользователей за сутки у нас 1 млн, а за

199:08

Speaker A

месяц 3 млн. Далее, предположим, что в среднем пользователь делает запрос к ленте 10 раз в сутки. Таким образом, можем рассчитать, что у нас будет 116 запросов в секунд. Но в реальности основная часть запросов будет приходиться на определённые пиковые

199:23

Speaker A

часы. Поэтому нужно отдельно участь этот фактор, чтобы понять, какой RPS должен выдерживать наши системы. Предположим, что в среднем один пост весит 500 Кб, а пользователь создаёт в среднем один пост раз в 50 дней. Исходя из этих данных, получим, что наша система будет занимать

199:41

Speaker A

10 ГБ данных в сутки и 3,6 ТБ в год. Наконец, вас могут попросить описать контракты APпоитов. Какие данные должны приходить и в каком формате. Давайте разберём на примере нашего кейса. Начнём с первой ручки, которая отвечает за создание поста. В эту ручку мы передаём

199:59

Speaker A

контент, который может содержать HTML-разметку. Это нужно, чтобы сохранить форматирование, которое сделал пользователь в редакторе. Также передаём изображение, в котором мы прокидываем ссылку на уже загруженную картинку, за которую отвечает у нас следующая ручка.

200:13

Speaker A

В неё мы передаём изображение в формате B64. Далее на бэкэнде это изображение сохраняется, например, в S3 хранилище и отдаётся ссылка на загруженную картинку.

200:23

Speaker A

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

200:42

Speaker A

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

200:56

Speaker A

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

201:08

Speaker A

Теперь перейдём к этапу погружения в детали. Секция на интервью очень сильно ограничена по времени, поэтому не получится детально обсудить все аспекты проектируемой системы. Поэтому важно согласовать с интервьюером список вопросов, которые потребуют детального анализа. Будет плюсом, если вы сами

201:26

Speaker A

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

201:48

Speaker A

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

202:05

Speaker A

Например, если с выходом каждой новой версии трудозатраты увеличиваются, например, количество сторипоинтов или увеличивается количество баков с каждой выпущенной фичой, это свидетельствует о плохой архитектуре и высокой связанности кода. Что можно отнести к архитектуре фронтда? На самом деле всё, что влияет

202:23

Speaker A

на организацию и качество кода, подходы к автоматизации, кодстайлы и конвенции, принятые в команде, выбранный стек, структура папок, разделение кода на слои и модули, организация работы с АИ и глобальным хранилищем, выбор основной парадигмы программирования и многое другое. Давайте более подробно поговорим

202:45

Speaker A

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

202:57

Speaker A

Для повышения качества кода рекомендуется использовать автоматизацию Prтер, Style Lint, Testint, Hask и CommitLint. С помощью ухаски можно интегрировать проверки в цепочку gate commitв, а коitlint позволяет писать осмысленные комиты по конвенции и поддерживать порядок в чейнджлогах. Не забываем про Typeesриpt. Статическая

203:18

Speaker A

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

203:26

Speaker A

Он должен быть актуальным и популярным. И вы должны быть уверены, что любая технология, которую вы выбираете, не пропадёт с рынка в ближайшие пару лет. В 2025 году я бы отдавал предпочтение именно View или React. Почему не Angнгуляр? В СНГ он менее популярен и

203:43

Speaker A

имеет малый процент использования в крупных компаниях, хотя при этом сам по себе фреймворк отличный. При этом выбор всегда зависит от контекста. Если компания использует Angгуляр и команда имеет экспертность именно в нём, то стоит рассмотреть его. Давайте пройдёмся по плюсам-минусам этих фреймворка. React

204:00

Speaker A

имеет самую большую экосистему и комьюнити. Больше всего вакансий на СНГ рынке, поддержка метаa, очень быстрый онбординг и найм и подходит для проектов любой сложности. При этом не фреймворк, а библиотека, поэтому множество решений вам придётся собирать самостоятельно.

204:18

Speaker A

Метафрейвок Next развивается хуже, чем его конкурент Next. И также React имеет очень большую конкуренцию на рынке. На 1.000 вакансий приходится 40 или 50.000 резюме. View с другой стороны - это полноценный фреймворк с прокачанной системой реактивностью. Имеет более низкий порог входа и простой синтаксис.

204:39

Speaker A

Отлично подходит для запуска MVP. Имеет декларативную шаблонизацию и такой же простой найм и онбординг. При этом View имеет меньшее комьюнити, чем у Реакта.

204:50

Speaker A

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

205:06

Speaker A

договорённости. Ангуular, в свою очередь, это самый большой фреймворк, который имеет множество всего из коробки, в том числе Typeesриpt, DI, декораторы и крутые архитектурные паттерны. Также он поддерживается Google. Хорошо подходит для больших команд с сотнями разработчиков. При этом имеет самый большой порог входа, большее

205:28

Speaker A

количество булерплейта, самая маленькая комьюнити на данный момент в СНГ и очень сильно усложняет найм и онбординг, ведь всего 4% крупных компаний используют Angular. Оставшиеся проценты распределены где-то поровну между View и React. Angular стоит рассмотреть, если у вас большой enterprise и есть опытная

205:48

Speaker A

команда, которая имеет экспертность именно в нём. для нашей системы возьмём View. В своём Telegram-канале я писал подробный пост о том, почему стоит изучать и переходить на Viewjs. Пост можно найти по поиску, вписав View.

206:02

Speaker A

Зачем вообще выбирать фреймворк вместо чистого джеса? Есть определённые критерии, почему большинство компаний выбирает писать на готовых фреймворках.

206:10

Speaker A

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

206:31

Speaker A

проект, не теряя контекст. Кроме того, использование фреймворков сильно снижает объём проектных знаний, что ускоряет найм и онбординг. и новые разработчики могут включаться в работу быстрее. Выбор стейт-менеджера. Если на прошлом шаге вы выбрали view, то тут всё просто.

206:47

Speaker A

Выбираем рекомендованное решение от фреймворка P. Если же выбран React, то стоит ориентироваться на современные и популярные решения, такие как RTK Query, redctol kit или ZUST. Важно понимать, глобальная система от выбранного state-менеджера не изменится. Это влияет в большей части на developer experience,

207:07

Speaker A

но важно понимать отличия и плюсы. минусы и уметь рассказать о них на собеседовании. Теперь перейдём к выбору режима рендеринка. Если требуется се оптимизация и хорошая выдача в поиске, то вместо React и Viewфреймворков стоит взять их метафреймворки Next или Next.

207:25

Speaker A

Можно рассмотреть и создание своего собственного решения, но тут важно понимать, что, несмотря на плюс в виде получения полного контроля над реализацией, вы получаете минус в виде повышенной сложности проекта и дополнительной точки отказа. Ведь это будет не Source решение, которое будет

207:43

Speaker A

валидироваться сообществом. Принцип работы SSR заключается в том, что он позволяет получать готовую HTML-страничку сервера, что улучшает SEO и ускоряет начальную загрузку. Помимо выбора разных режимов френдера, метафреймворки добавляют удобный файл baseутинг и удобную работу с запросами и кэшированием. Тут важно уточнить, что

208:05

Speaker A

даже если вы выбрали по умолчанию SSR-режим, то не все страницы нужно генерировать на сервере. Страницы закрытой зоны, требующие авторизации, обычно не нуждаются в SEO, а значит, и в серверном рендеринге. Страницы с редко меняющимся контентом и без персонализации например список

208:23

Speaker A

категорий в приложении для еды стоит генерировать как SSG. HTML в таком случае будет генерироваться на этапе билда, что обеспечит очень быстрый рендер. При этом, если требуется периодическая ревалидация таких страниц, то стоит рассмотреть подход Incremental Stytic Regeneration. В NextJS это

208:41

Speaker A

делается через опцию Revolidate, а в Наксте есть специальный режим ISR для роутов. Сгенерированной странице шируется на CDN на указанное время, после чего регенерируется. Давайте рассмотрим выбор режима рендеринга на основе нашей задачи. Мы хотим, чтобы наши посты хорошо индексировались

208:57

Speaker A

поисковыми системами, но поисковики не видят бесконечный скрол, а у нас он точно будет для оптимизации. Они видят только HTML, что пришёл при первом рендере. Поэтому, чтобы решить эту проблему, мы можем отдавать сервера страницы профилей и отдельные твиты, а

209:12

Speaker A

саму ленту генерировать на клиенте. Таким образом, основной контент ленты попадёт в ранжирование. При этом хочу обратить внимание, что можно использовать SSR только для ботов, чтобы улучшить SEO и ранжирование, а реальных пользователей всегда вести на ИПА. Такой подход тоже часто используется в

209:28

Speaker A

проектах. Теперь перейдём к выбору методологии и архитектур. Что у нас есть в мире фронтенда? классическая архитектура, то, как строится у вас проект, когда вы просто берёте фреймwork. Компоненты в папке components, страницы в папке pages, вспомогательные функции в папке Helpers.

209:45

Speaker A

Из плюсов быстрый старт проекта, минимум барьеров для новых разработчиков и хорошо подходит для MVP. Минусы: имеет ограниченное масштабирование. Если проект разрастётся, то кодовая база очень быстро превратится в хаос. Хороший вариант для маленьких и быстрых проектов, но проигрывает в долгосрочной

210:02

Speaker A

перспективе. Модульная архитектура. В ней код группируется по модулям или доменам. Например, Autch, проаль Fit.

210:10

Speaker A

Каждый модуль может содержать свои компоненты, стили и сервисы. Плюсы - это достаточно масштабируемо. Новые модули легко добавлять, при этом модуль изолирует всё нужное в себе. Минусы: может быть много дублирования. Очень сложно определить границу модуля. могут быть проблемы с кросс-импортами модулей.

210:30

Speaker A

АOMIC дизайнign архитектура, ориентированная на UI-компоненты, имеет декомпозицию слоёв: атомы, молекулы, организмы, темплейты и страницы. Из плюсов это очень простая архитектура.

210:42

Speaker A

Она отлично подходит для дизайнсистем и UIтов и легко поддерживать единый стиль во всём приложении. Главный минус, она никак не решает вопроса бизнес-логики и разделения ответственности. Future Slice Design - архитектурная методология, придумана конкретно для фронтendнд приложений. Из плюсов, она

211:00

Speaker A

бизнес-сориентированная. Мы выделяем бизнесовые сущности entities и пользовательские сценарии фичи. Имеет однонаправленный поток данных и иерархию слоёв. Также изоляцию с помощью пабли.

211:13

Speaker A

Можно внедрять постепенно и итеративно. Минусы: высокий порог входа избыточно для маленьких проектов, требует экспертной команды и договорённостей.

211:24

Speaker A

могут быть проблемы с кросс-импортами и необходимости в создании новых слоёв. Чистая архитектура. Архитектура, которая выделяет слои от бизнес-домена до юа.

211:34

Speaker A

Бизнес-логика при этом полностью отделена от UI и инфраструктуры. Плюсы: имеет максимальную гибкость. Можно менять фреймворк без переписывания ядра.

211:43

Speaker A

Также имеет максимальную масштабируемость и тестируемость. Минусы: огромный порог входа, большая сложность и много абстракций. сильно усложняет найм и онбординг. Плохо подходит для фронтенда, где редко, когда нужно менять UI фреймamework на леду. В 99% случаев я бы не рассматривал такой

212:01

Speaker A

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

212:22

Speaker A

сложность решения. На данный момент в большинстве случаев я бы отдавал предпочтение именно ФСД за счёт своих плюсов. Именно эту методологию и возьмём для нашего кейса. Что по поводу дизайн-системы? Тут возможности очень обширные. Существует огромное количество готовых UI библиотек и фреймворков, но

212:39

Speaker A

их не всегда стоит использовать. Если проект планирует развиваться и поддерживаться долго, то готовая дизайн-система будет сильно ограничивать дизайнеров, а время от времени придётся переписывать компоненты. Готовые UI библиотеки отлично подходят для внутренних проектов, где нет необходимости к строгому соблюдению

212:58

Speaker A

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

213:11

Speaker A

При этом важно помнить про изоляцию стилей, чтобы не допускать утечек и конфликтов. Например, использовать, CSS-модули или CSSNGS. В нашем случае будем писать компоненты сами и возьмём классический BМ. Теперь хочу немного поговорить про способы организации кода.

213:28

Speaker A

Есть четыре основных способа. Монолит. Всё приложение живёт в одном репозитории и одной кодовой базе. Плюсы: просто деплоить и разрабатывать небольшие и средние приложения. Имеет минимальные расходы на отдел эксплуатации в части организации CICD, мониторинга и объёма серверных мощностей. Минусы: при росте

213:49

Speaker A

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

214:08

Speaker A

кэширования компонентов и страниц. Микрофронтенды - архитектура, которая делится на независимые модули, за которые отвечает отдельная команда и деплоится независимо. При этом команда может соблюдать свои собственные комменции и иметь свой собственный стек.

214:24

Speaker A

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

214:45

Speaker A

компаний с большим количеством разработчиков, где альтернативные решения имеют больше минусов, чем плюсов. Монорепозиторий. Один репозиторий, в котором находится несколько пакетов. Подходит, когда несколько команд разрабатывают продукты, в которых можно явно выделить один общий КОР. Пример, отдельно реализуемые версии для ПК и мобильных устройств. Они имеют

215:07

Speaker A

единый Core, единые helpпер функции и единые сторы, но при этом имеют разные UI. Плюсы позволяют переиспользовать общий корных клиентов. При этом не нужно выпускать отдельный релиз при изменении в коре. Из минусов: каждая команда может изменить общий пакет и выстрелить в ногу

215:25

Speaker A

другой команде. Поэтому это требует большой дисциплины и ответственности при работе с общим кором. NPM-пакет. Код оформляется как отдельная библиотека и публикуется в NPM. Актуален, когда одна команда делает универсальное решение для n-команд. Плюсы: единая точка ответственности, управляемая независима.

215:46

Speaker A

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

216:04

Speaker A

Выбор подхода зависит от масштаба проекта и задач. В нашем случае подходит обычный монолит, а UI бибблиотеку будем держать в папке Shar UI по ФD. Теперь давайте поговорим про BFF. BFF расшифровывается какэнд for front-end.

216:20

Speaker A

Это слой между фронтэндом и бэкэндом, за который часто могут отвечать именно фронтендеры. Также BFF может выступать как дополнительная прослойка между различными бэкэндами, которые не адаптируют свои контракты под разные клиенты. Цель такой прослойки - унификация контрактов и реализация необходимых SL, например, по

216:38

Speaker A

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

216:57

Speaker A

логика обработки данных и уменьшение по сетевым вопросам, так как часто БФ находится в одной приватной сети с клиентами. Минусы: это дополнительная инфраструктура и потенциальная точка отказа. чаще всего не предусматривает фулбк на изначальные бэкэнды, из-за чего при недоступности БФФа все клиенты

217:16

Speaker A

умрут. Увеличивает затраты на разработку и поддержку. Необходимая синхронизация между бэкэндом и фронт-тендом. В случае неправильной эксплуатации БФ может превратиться в толстый эээкэнд. В рамках нашей задачи БФ не нужен. Если в нефункциональных требованиях сказано, что системой должны пользоваться люди с

217:35

Speaker A

ограниченными возможностями, то стоит уделить время доступность. Для этого применяются ариатрибуты и табндекс. Давайте рассмотрим доступность на примере нашего кейса с лентой новостей.

217:46

Speaker A

У нас есть такой пример вёрстки. Area labeled by newsfeed heading говорит о том, что заголовок для всей секции берётся из элемента с IDF heading. Area life polite превращает элемент в живой блок с уведомлениями. Когда текст внутри этого блока меняется, скриндера

218:02

Speaker A

автоматически зачитает его пользователю. Pй означает озвучь, но не перебивай текущую речь. Ещё есть assertive.

218:10

Speaker A

Завершай текущий текст и озвучивай этот. Здесь newsfeed stat стаatus будет динамически сообщать, что добавлено N постов. Newsfit loading будет сообщать, что загружаем новую порцию постов. Класс SR only делает элемент невидимым для обычных пользователей, но доступных для скриндеров. Rollfeit - это а area pat

218:28

Speaker A

паттерн, который обозначает потоковый список постов. Он ожидает дочерние элементы с ролями article или document.

218:35

Speaker A

Area Described by Newsfeed Info связывает ленту с блоком информации. Скриндеры при фокусе на ленте зачт текст из скрытого блока. Это даёт пользователю дополнительный контекст. В ленте шесть постов, навигация с помощью таба. Area labeled by post title говорит о том, что

218:50

Speaker A

озвучиваемым заголовком этого поста будет H3 с ID post title. Там 0 делает весь пост фокусируемым, чтобы пользователь мог перемещаться между постами. Area labable у button задаёт понятное имя кнопки. Без него скриндер бы попытался прочесть символ и цифру, что не всегда очевидно. Теперь будет

219:07

Speaker A

текущее количество лайков 47. Area life po light. Если число лайков изменится, Screen Reader озвучит обновление. Area has popup menu указывает, что кнопка открывает меню. Area expanded false показывает текущее состояние меню. При открытии меню нужно переключить на true.

219:24

Speaker A

Area controls reactions menu Post ID связывает кнопку с меню, которую она открывает. Area Hidden True от скриндеров, иначе они дополнительно пытались бы озвучить эмодзи. Rollл-меню определяет контейнер как меню. Rollлменю Item говорит, что дочерние элементы - это пункты меню. Area hidden true. Меню

219:43

Speaker A

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

220:00

Speaker A

Теперь настало время обсудить оптимизацию производительности. Мы не будем здесь обсуждать, как ускорить запросы на бэкэнд, а сконцентрируемся именно на фронт-энд оптимизациях.

220:10

Speaker A

Некоторые аспекты мы уже косвенно затронули при обсуждении метафреймворков. CSR позволяет ускорить time to first pain, то есть первую отрисовку контента. Также мы не будем тут останавливаться на различных кодсплитингах, оптимизациях пандла, при фечах, мемоизациях и динамических компонентов. Всё это часто уже

220:29

Speaker A

реализуется фреймворком из коробки и достаточно просто настраивается. Итак, что ещё нам может помочь в оптимизации?

220:35

Speaker A

Про CDN уже упоминали в прошлых главах. Давайте рассмотрим дополнительные способы по оптимизации изображений. Нужно использовать современные стандарты. Предпочительно VP вместо JPEG PNG для экономии трафика и ускорения ресурсов. Но учитывайте, что VP может не поддерживаться в старых браузерах. Тут

220:52

Speaker A

нам поможет тег, который позволяет указать сет картинок с фулбком для старых браузеров и позволяет загружать изображения в зависимости от размера экрана. Также можно добавить lazy loadдинг для картинок. Изображения будут загружаться только при попадании в область видимости пользователя.

221:08

Speaker A

Оптимизация погинации. Существует два основных подхода к реализации погинации. Офсет и курсор. Офсеset погинация работает с параметрами лимит количества элементов на странице и offset отступ.

221:20

Speaker A

Из плюсов можно легко переместиться на конкретную страницу. Также это легко интерпретируется на бэкэнде. Минусы: с ростом офсе запросы замедляются, так как СУБД должна пройти все записи до нужной позиции. И также может быть дублирование записей в ленте для часто обновляемых

221:37

Speaker A

данных. Например, мы посмотрели пять постов, но за это время появилось ещё пять записей. Мы грузим следующую пачку, у нас происходит отступ, и мы видим опять те же самые пять постов. Поправить это можно, но дополнительными костлями на фронт-тенде. Курсор пагинация, в свою

221:54

Speaker A

очередь, работает с параметрами size, количество элементов на странице, и курсор, указатель на ID, тайм стеamp или другой специфичный параметр, который указывает, от какого элемента получать следующую порцию данных. Из плюсов у нас нет проблем с замедлением запроса при больших отступах. И также это отлично

222:11

Speaker A

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

222:28

Speaker A

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

222:44

Speaker A

фиксированное число, например, шесть постов. Но если у пользователя маленький экран и он видит одновременно всего два поста, то это приводит к избыточным ресурсам на запрос. Более оптимальный вариант- динамический определять количество элементов в зависимости от экрана пользователя. Например, если

223:01

Speaker A

пользователи видят всего два элемента, можно запросить столько же плюс небольшой запас. Также хорошая UX практикой считается, когда пользователь не видит загрузок и лоудеров совсем. То есть данные загружаются немного заранее, например, когда пользователь доскролил до 80-90% контента. Для того, чтобы это всё

223:21

Speaker A

реализовать, у нас есть два варианта: Intersection Observer App и обычный Scrollроoll. Intersection Observer - это нативное современное решение, в котором не нужно дополнительно оптимизировать сам обработчик, ведь внутри используется request idle callback для оптимизации.

223:37

Speaker A

Также у нас есть возможность вешать несколько наблюдателей. Единственный минус - это решение не поддерживается в очень старых браузерах. Поэтому, если нам важно их поддерживать, то можно рассмотреть реализацию через обычный срол и getbounding client trct. Такое решение будет работать везде, и у нас

223:55

Speaker A

будет полный контроль над реализацией. Но при этом нужно будет самостоятельно оптимизировать обработчик скрола и вызова getunding client trct, например, используя debounce или drotтling.

224:05

Speaker A

Виртуализация - это приём во фронт-нде для оптимизации работы с очень большим списком элементов, например, ленты и соцсети. Если отрентрить в дом тысячи элементов, то приложение сильно замедлится, нагрузится память и ухудшится плавность скрола. Что делает виртуализация? Мы остальные элементы

224:23

Speaker A

заменяем пустыми контейнерами с правильными размерами, чтобы контент не скакал при скроле. Когда пользователь скролит, новые элементы загружаются динамически, а старые удаляются из дома.

224:35

Speaker A

Таким образом, для пользователя лента выглядит плавной и бесконечной, но в реальности в дом может находиться всего 20 или 30 элементов. Это можно реализовать через visability hidden и фиксированную высоту элементов или же воспользоваться готовыми библиотеками, например, React Window или View Virtual

224:53

Speaker A

Scroll List. К минусам такого подхода можно отнести, что это усложнит логику подскрола к элементу и сложнее реализовать, если размер элементов динамический. Если в рамках продукта есть пользовательское действие, например, клик по реакции или добавление товара в корзину, которая отправляет

225:11

Speaker A

запрос на энд, то можно применить оптимистик Update. Идея в том, что при клике на кнопку пользователь ожидает, пока придёт ответ от сервера, и не понимает, что-то произошло в системе. И также у нас возможны двойные клики.

225:25

Speaker A

Optimistic Update - это когда мы сразу обновляем UI после действия пользователя, а не дожидаемся ответа с бэкэнда. Но если с сервера приходит ошибка, то мы откатываем изменения в UI и показываем ошибку. По сути, это способ замаскировать сетевые задержки и сделать

225:41

Speaker A

интерфейс более отзывчивым. Нормализация данных - это практика организации кода таким образом, чтобы каждая сущность хранилась в одном месте, а взаимосвязи между сущностями выражались через идентификаторы. Это позволяет избегать дублирования данных, упрощать обновление и удаление данных и оптимизировать производительность фронтда. Особенно в

226:01

Speaker A

реактивных приложениях, когда часто меняется только часть данных. Противоположность нормализованного хранилища денормализованная. Там данные дублируются, что упрощает чтение, но вызывает трудности при изменении данных.

226:15

Speaker A

И Facebook, и Twitter используют нормализованное клиентское хранилище. Facebook использует Relay, Twitter использует Redx. Преимущество нормализованного хранилища: меньше дублирования данных. одна истина для одного и того же куска информации, который может отображаться в разных местах системы. Например, у многих постов один и тот же автор. Без

226:34

Speaker A

нормализации его данные будут дублироваться в каждом посте. Также легко обновлять данные для одной сущности. Если у пользователя много постов в ленте и он сменил имя, нужно сразу отобразить новое имя во всех постах. С нормализованным хранилищем это просто. Обновили одну запись автора, и

226:50

Speaker A

изменения применились во всех местах. Но это требует дополнительного кода для сбора данных и дополнительные затраты на нормализацию. Придётся писать БФF прослойку или пользоваться готовыми решениями в виде нормалайзера. Для новостной ленты в контексте интервью нормализованное хранилище не обязательно, потому что кроме поля автор

227:10

Speaker A

других дублированных данных не будет. Также лента используется в основном для чтения. Реакции меняют только локальный пост. По итогу преимущества нормализации данных раскрываются в реальных и больших продуктах. таких как Twitter и Facebook, где данные встречаются в различных частях системы. Если рассматривать

227:28

Speaker A

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

227:44

Speaker A

Вместо того, чтобы отправлять запрос на каждый символ, мы дожидаемся n мисекунд после последнего нажатия и отправляем один запрос. Этот приём хорошо применять при поиске, валидации форм, при ресайзе окна и обработке скрола. Он позволяет избежать лишних запросов, уменьшить нагрузку как на фронт-энд, так и на

228:03

Speaker A

бэкэнд и сделать интерфейс более стабильным. Но важно понимать и минусы. Во-первых, появляется небольшая задержка в интерфейсе, пока мы ждём тайм-аут.

228:11

Speaker A

Во-вторых, если мы используем кэширование результатов, то при частых исправлениях и опечатках полезные варианты могут не сразу попадать в кэш.

228:19

Speaker A

Например, пользователь ошибается и вместо меil пишет меilль. И мы кэшируем результат для неправильного запроса.

228:25

Speaker A

Потом пользователь стирает один символ, и мы заново отправляем запрос на уже нужный query. Graceful degradation или плавная деградация - это подход, при котором приложение продолжает работать даже в условиях ограничения, будь то медленный интернет, слабые устройство или отключённый JavaScript. При этом

228:42

Speaker A

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

228:58

Speaker A

ошибку, но при этом продолжать смотреть посты и создавать их. Если в другом продукте не работает модуль подписок, то мы всё равно должны дать пользователю доступ ко всему бесплатному контенту, не падая в аварийный экран. Таким образом, пользователь остаётся в продукте и может

229:14

Speaker A

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

229:27

Speaker A

Тесты обеспечивают предсказуемость разработки, а метрики - предсказуемость эксплуатации. Без тестов команда рискует сломать старый функционал при выпуске новых фичей. Без метрик продукт превращается в чёрный ящик, где мы не понимаем, как он работает у пользователей, пока не начнут сыпаться

229:43

Speaker A

жалобы. В этой части мы разберём, как правильно подойти к обоим аспектам. Зачем вообще нужны тесты? Представьте, что вы реализовали бизнес свечу, написали весь код. Но как проверить, что она работает так, как задумана? Без тестов можно полагаться только на ручные

229:58

Speaker A

проверки, а это сразу увеличивает нагрузку на QA отдел. По мере роста системы, когда одна фича может затрагивать другие, мы быстро придём к ситуации, когда количество проверок при регрессе в рамках одного релиза может стать просто нерентабельным. Тесты позволяют экономить ресурсы на средние и

230:17

Speaker A

длинные дистанции, снижая стоимость сопровождения системы. Кроме того, они выступают как документация поведения системы. Зачастую намного проще посмотреть описанные тест-кейсы, чем разбираться в 500 строчках кода компонента и понимать, какую бизнес-ценность он несёт. Нужно ли писать тесты? Здесь важен контекст. Если

230:35

Speaker A

мы говорим про MVP и проверку теории бизнеса на рынке, то зачастую время разработки намного важнее, чем написание тестов. В таком случае можно либо не писать тесты вовсе, либо ограничиться минимальными автотестами для критических сценариев. Если же система работает уже

230:51

Speaker A

в продакшене, приносит деньги и должна быть стабильной, тесты становятся обязательными. Они помогают предотвратить регрессии и упрощают разработку системы. Минусы тестов тоже есть. Для их написания нужен опыт и понимание, как писать хорошие, а главное, полезные тесты. И также часть

231:08

Speaker A

времени разработки будет уходить на покрытие кодовой базы вместо реализации новых бизнес вечей. На собеседовании важно уметь аргументированно объяснить, когда покрытие тестами оправдано, а когда нет. Как покрыть приложение тестами. Существует пирамидатестирования. Это модель, которая показывает, какие тесты писать и

231:26

Speaker A

в каком соотношении. Основные принципы следующие. Не пишем тесты на то, что проверяется типизацией и статическими линтерами. Пишем много юнит-тестов, так как они быстро пишутся и проверяют целый модуль. Интеграционных тестов пишем в меньшем количестве, чтобы проверить взаимодействие нескольких модулей

231:43

Speaker A

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

232:00

Speaker A

роботоспособность, целесообразно начать с ету-тестов на критические сценарии. Это даст максимальную ценность при минимальных усилиях. Но важно понимать, что етуе-тесты могут дать ложное представление о проценте покрытия. Один большой-тест может дать сразу большой процент, хотя отдельные модули в изоляции не тестировались. Также

232:19

Speaker A

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

232:39

Speaker A

внедрить тесты в существующую систему. В новой системе лучше писать тесты сразу. Контроль качества приложения не заканчивается релизом. Тесты нужны до релиза, но после приложение продолжает работать и ломаться. Поэтому важно иметь процесс мониторинга и наблюдаемости. Без этого любые тесты в Cш частичную

232:59

Speaker A

гарантию стабильности. Пройдёмся по основным элементам контроля качества. Один из способов сбора метрик - это Prometeus. Prometeus - это система, которая собирает, агрегирует и хранит метрики. Примеры собираемых метрик - это время ответа, а, среднее количество активных пользователей, загрузка страницы, webfitles и другие

233:18

Speaker A

альтернативные метрики, которые мы хотим собирать. Собранные метрики нужно уметь интерпретировать. Самое популярное корпоративное решение - это графан. Она позволяет строить наглядные графики и дэшборды и настраивать алерты. Например, мы можем видеть среднее время ответа сервера, количество падений АИ и среднее

233:36

Speaker A

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

233:55

Speaker A

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

234:13

Speaker A

часть мониторинга - это своевременное информирование о критических проблемах. Для этого можно настроить алерты в графане или Прометеус и получать уведомления в корпоративный мессенengжеer, если метрики выйдут за пороговые значения. Такой подход к организации системы мониторинга на клиентах обеспечивает полный цикл

234:31

Speaker A

производительности и стабильности от пользовательского опыта до корректной работы всех CGМов. В качестве домашнего задания я предлагаю вам спроектировать масштабируемую архитектуру для компонента поиска в интернет-магазине.

234:44

Speaker A

Ваша задача - полностью пройтись по всем пунктам, что мы сегодня обсудили, от сбора функциональных требований до вопросов оптимизации и метрик. Ну а подробный разбор решения этой задачи смотрите на бусте. На этом мы завершаем главу по системному дизайну во фронтде.

235:00

Speaker A

Спасибо за внимание. Я Антон, мобильный разработчик и ментор. В этой главе я расскажу про системный дизайн мобильной разработки. У нас будет четыре части. Мы поговорим про то, как системный дизайн у нас проводится на собеседованиях и как он используется в

235:18

Speaker A

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

235:37

Speaker A

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

235:47

Speaker A

Также многие компании переходят к mobile first подходу. Всё это говорит о том, что мобильный разработчик очень важен, а также важно стримить с экспертом в своей области. В этой части мы разберём, как можно подготовиться к собеседованиям, а также подготовиться к работе мобильного

236:03

Speaker A

разработчика. Ещё разберём, в чём экспертность мобильного разработчика и как стать успешным разработчиком. Роль мобильного разработчика. Мобильный разработчик отвечает за то, а как выставить контракты с бэкэндом для того, чтобы эффективно управлять данными.

236:22

Speaker A

Также отвечает за проектирование верхнеуровневого приложения, за проектирование фичильности, отвечая за стабильность ишфри, а также за релизы и стабильность вечей. Разберём подробнее каждый пункт. Апи с бэкэндом.

236:36

Speaker A

В целом, а может быть проработана как бэкэндером, так и системным аналитиком, и это всё зависит от компании. Но сильный мобильный разработчик может спроектировать АПИ не только на собеседовании, но и на работе. И причём может спроектировать АПИ не только для

236:50

Speaker A

контрактов между мобилкой и бэкэндом, но ещё между бэкэндами. Всё это говорит о его экспертности, но это уже Senior плевеel. Важная пометка то, что составление АИ обычно включается в проектирование приложения. и используется на интервью. Архитектура приложения и фич. Архитектура приложения

237:08

Speaker A

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

237:27

Speaker A

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

237:43

Speaker A

Мобильные системы хоть и работают на одном устройстве, но так как на всех устройствах одна версия приложения, если будет критичный баг или крэш, то он будет у каждого пользователя. Для того, чтобы ограничить пользователей от крышей и багов, придумали фичерфлаги. Это

238:01

Speaker A

некоторые флаги, которые приходят с бэкэнда и управляют поведением клиента. Также самой главной проблемой мобилки является высокий time to market. Он обычно составляет от одной до 2 недель.

238:13

Speaker A

А с помощью фичфлагов можно выключить или включить фичу буквально за одну минуту, просто придав новый конфиг. Для того, чтобы мониторить проблемы с кршфри и с аналитикой и какими-то багами из функциональностей, можно использовать метрики, например, для кШashфри метрики Firebase, а для метрик аналитики

238:32

Speaker A

обметрику. Релизы приложения и выкладка фичей. На первый взгляд релизы не относятся к системному дизайну, но так как это узкое горлышко мобильной системы, были придуманы некоторые техники, которые позволяют ускорить time to market. Например, Backend Driving UI.

238:48

Speaker A

О нём мы поговорим в четвёртой части. С помощью него можно перейти от одной или двух недель к одному или двум дням для релиза. И архитектура вместе скнен становится абсолютно другой. Именно поэтому стоит спрашивать на интервью, а какой time to marкеet мы хотим выбрать

239:05

Speaker A

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

239:24

Speaker A

уже будет сложность в том, что нужно покопаться вглубь и выделить правильные подходы и паттерны для того, чтобы ваша веча выглядела хорошо и вы могли использовать те же подходы для других вещей. Либо же это может быть что-то совсем кастомное, например,

239:39

Speaker A

проектирование библиотеки, проектирование отдельного какого-то сервиса для дизайнсистемы и так далее. Здесь сложность в том, что задача может меняться в зависимости от компании, интервьюеры и грейда, на который вы собеседуетесь. Поэтому подготовиться полностью к этой задаче невозможно.

239:54

Speaker A

Можно лишь основываться на тех практиках, которые мы обсудим в этой главе. Итогом интервью, а, становится спроектированное приложение, библиотека или фича в каком-то сервисе проектирования. Обычно это выглядит как некая UML или недодиаграмма со стрелочками, надписями и подписями.

240:13

Speaker A

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

240:27

Speaker A

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

240:42

Speaker A

приложении, как они должны взаимодействовать с бэкэндом и как действовать в случае ошибки или загрузки. Для нефункциональных требований нужно узнать, какой размер команды, отслеживать метрики крэшей, как отслеживать метрики скорости приложения, а также какой стек у команды и какой time to market мы хотим. Второй этап -

241:00

Speaker A

это проектирование апи. Здесь вы хорошо должны быть знакомы с основными протоколами для связи с бэкэндом. Это rest, websocket или сервис and events, oв 2 и access fresh токены, long и short polling, погинация и грав QL. Всё это нужно знать хотя бы на базовом уровне

241:17

Speaker A

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

241:33

Speaker A

как мы хотим масштабироваться и изменять приложение в ближайшие релизы, и какой мы хотим time to marкеet. О верхнеуровневой архитектуре мы подробно поговорим в третьей части этой главы.

241:43

Speaker A

Также на этом этапе нужно выделять проектирование фичи. Это достаточно важная часть, а потому что она требуется не только на интервью, но и когда вы проектируете приложение на работе, если у вас фича дороже, допустим, 2ву недель.

241:57

Speaker A

Для нативного приложения с монолитом или многомодностью я рекомендую выбрать ту архитектуру, которая вам нравится, и постоянно использовать её на собеседовании. Из важных требований, которые нужно использовать, я выделяю скорость её проектирования на интервью, то есть насколько быстро вы сможете

242:13

Speaker A

нарисовать все эти квадратики, а также насколько хорошо архитектура подойдёт к большому скоупу вещей. Конкретно для меня на Android я выделяю Cleen Architecture, где у меня есть presentation доме и датаслои, а также MVVM+ state. Довольно лаконичная архитектура, которая хорошо подходит под

242:30

Speaker A

большинство приложений. Если же у нас задача более сложная, то здесь можно подумать уже в сторону MVI.

242:35

Speaker A

Проектирование библиотеки. Здесь случается конечный пользователь. Это уже не пользователь, который скачал наше приложение в маркете. Это уже разработчик, который будет использовать нашу библиотеку, а точнее её апи, для того, чтобы писать новый код. Поэтому конечный результат у нас будет немножко

242:50

Speaker A

отличаться. Мы не сделаем презентационный слой с экраном. Мы будем делать апи, которая будет связывать нашего разработчика с нашей библиотекой.

242:58

Speaker A

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

243:13

Speaker A

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

243:29

Speaker A

функциональные и нефункциональные требования, мы обговорим. Далее, узкие места для мобильного разработчика. Бутылочным горлышком для мобильного разработчика может стать всё, что угодно, разве что, кроме Restp. Это и вебсокеты, иглинг, и се, и авторизация, и надёжность системы, и метрики Crashf,

243:48

Speaker A

и работа с SSL и sellсертификатами, шифрование, двухкторная аутентификация. Всё это стоит изучить прежде чем пытаться спроектировать систему, которая должна отвечать таким требованиям.

243:59

Speaker A

Паттерны мобильного разработчика. На интервью стоит пользоваться паттернами, и можно выделить ряд паттернов, которые очень часто приходится использовать на работе и на собеседовании для именно мобильного разработчика. Это обсервер, sletлon адаптер декоратор factory а также MV паттерны для презентационного слоя. Что же оценивают на собеседовании?

244:19

Speaker A

Обычно на собеседованиях оценивают картину целиком, либо какие-то определённые этапы очень глубоко. Но в целом, чтобы хорошо пройти интервью, нужно уметь не расслабляться на протяжении всего интервью и быть в фокусе. Если вы хорошо спроектировали А, то если вы расслабитесь на верхне

244:36

Speaker A

уровней архитектуре или на проектировании Фичи, это пойдёт вам боком, и вас могут заводить. Если же у вас получилось не очень хорошо собрать функциональные и нефункциональные требования, то здесь вы можете их дособирать на этапе проектирования фичим-то другом этапе. То есть в любом

244:51

Speaker A

случае нужно идти до конца и стараться изо всех сил. Как подготовиться к системдизаign интервью для мобильного разработчика? Посмотреть эту главу, спроектировать архитектуру для домашнего задания, посмотреть ответ на бусте и сравнить с тем, что получилось у вас, пройти мог интервью или реальное

245:09

Speaker A

интервью. Профит: Ты стал сеньором или синьоркой? Архитектурное интервью - это, пожалуй, один из самых лучших способов протестировать разработчика на профпригодность, потому что все навыки, которые вы получаете для подготовки к собеседованию, вы получаете на работе, либо вы получаете те навыки, которые вы

245:26

Speaker A

можете применять на работе. То есть это сугубо практическое интервью, и чем выше ваш грейд, тем, скорее всего, лучше вы будете проектировать. Часть два. А и AP.

245:36

Speaker A

Целью раздела является показать с нуля, как спроектировать Апи для быстрой работы мобилки и для классного взаимодействие с бэкэндом. На собеседовании важно узнать направление и глубину проработки А. Обычно на этот этап уделяется от 5 до 10 минут, поэтому здесь не стоит очень сильно углубляться.

245:55

Speaker A

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

246:13

Speaker A

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

246:25

Speaker A

До рисования энпоинтов важно задать некоторые вопросы. Они могут быть например, такими. Важно узнать про целевую аудиторию, про её размер, это MAO и Да, метрики, а также про то, какими устройствами они будут пользоваться. Возможно, это дешёвое устройство, и поэтому вся логика должна

246:40

Speaker A

перекачевать на ээкэнд, потому что телефоны не смогут её воспроизводить. А также по Mao и DAO нужно обсудить, как API будет уменьшать количество запросов либо ускорять ответы. Это может быть рейлимитинг или обрезка ответа, оффлайн и онлайн-подход. Здесь важно понять,

246:59

Speaker A

нужен ли нам кэш и как часто нам нужно его обновлять. И какой у нас stilness SLA. Если вы видите, что работа происходит со списками, скорее всего, здесь должна использоваться погинация, ну или же другие realтайм-стратегии.

247:12

Speaker A

Здесь стоит обсудить триггеры, переподключение, а также время до переподключения и какая у нас итоговая задержка для отправки ответа. То есть доставить не позже, чем за, допустим, 10 мскунд или 100 мскунд. Ну и один из важных вопросов - это команда и

247:30

Speaker A

скорость, то есть кто владеет АПИ, кто в принципе должен это АПИ более детально прорабатывать, а также кто отвечает за то, чтобы АПИI менялась и разработчики, мобильные, разработчики бэкэнда узнавали об этих изменениях. Обычно АИ владеет системной аналитикой или бкндер

247:47

Speaker A

какой-то, который является head of чего-то, ну либо это может быть фича лидер какой-то функциональности или направления бизнеса. Он уведомляет всех причастных, если меняется апи. Обсудим протокол взаимодействия с бэкэндом, который мы обсуждали ранее. Самый первый главный - это Rest AP. Он создан для

248:06

Speaker A

create, read, update и delete операций, а также для простых списков. Для realtime обновлений у нас существует несколько вариантов. Либо Websocket для полнодуплексного соединения, либо сервер Sent Events, который может использоваться для однодуплексного соединения. Для взаимодействия между бэкэндами обычно выбирается JRPC. Его

248:23

Speaker A

любят за низкие задержки и удалённый вызов процедур. Иногда нам требуется некий эээнд for frontend - это тот ээкэнд, который будет отвечать за логику отрисовки, за логику, которую мы хотим не тащить в мобилку. Для того, чтобы удобнее обращаться к этому бэкэнду и

248:40

Speaker A

общаться с ним, можно пользоваться графэлем или другими агрегирующими шлюзами. Пуши. Здесь в целом можно пользоваться уже существующими решениями, например, Firebase Push Notification Service или Rore Push Notification Service. Но если вы захотите внедрить пуши самостоятельно, то здесь стоит пользоваться подходом из

248:59

Speaker A

север sent events или полинга вместе с каким-то бэкграунд оператором, который будет это выполнять. Конкретно в Андроиде можно воспользоваться ворк-менеджером либо же сервисом. Важно обсудить конвенции, которые позволят вам спроектировать апи так, чтобы его можно было развивать. улучшать, и ваш клиент

249:17

Speaker A

от этого не страдал. Самая важная конвенция - это версионирование. Для любой ручки хорошо сделать V1 или V2 и так далее, потому что если ручка меняется, не меняются поля, то старые версии перестают работать корректно, а многие пользователи сидят на старых

249:35

Speaker A

версиях, поэтому мы должны их поддерживать. Также сюда можно добавить заголовок XClient version. Он позволяет нам отдавать данные, исходя из версии приложения. То есть это уже версионирование, которое заложено не в апе, а в логику самого бэкэнда.

249:49

Speaker A

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

250:11

Speaker A

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

250:23

Speaker A

Это курсор погинация, где мы передаём некий курсор. Также для списков, которые основаны на daytime, можно передавать время, и тогда у нас не будет проблем с тем, что какой-то элемент удалили, и мы не можем получить следующие элементы, и у нас данные повторяются. Импонентность

250:39

Speaker A

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

250:57

Speaker A

допустим, транзакция с переводом денег не отправилась дважды. Для ошибок стоит выделить отдельный формат. Это могут быть коды ошибок, сообщения какие-то в виде стринги, либо массивы с деталями об ошибке. Един формат упрощает обработку на клиенте. И если эта конвенция будет

251:14

Speaker A

соблюдаться от бэкэнда к эээкэнду и разные бэкэнды, которые используют одно мобильное приложение, будут обрабатывать ошибки одинаково, то мобильным разработчикам будет очень просто внедрять новые фичи изменять предыдущие.

251:25

Speaker A

Локаль и таймзона. Сейчас мы постоянно работаем со временем. Это и время сообщений, время лайка, время поста и так далее. Поэтому важно правильно и корректно с ними работать. Так как мы все находимся в разных городах, в разных таймзонах, у нас могут быть два

251:39

Speaker A

варианта. Либо мы с бэкэнда отправляем время в UTC00, либо мы отправляем время специфично для клиента, получая от клиента header с его таймзоной. Теперь поговорим про надёжность. Этот пункт больше относится к бэкэнду и к проектированию апи со стороны бэкэнда,

251:56

Speaker A

но если о нём вы расскажете на интервью на мобильного разработчика, то это опять же даст вам какое-то количество баллов.

252:03

Speaker A

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

252:21

Speaker A

вам нужно иметь короткий time to life вашего кэша. Это может настраиваться Stainless SLA либо другими техниками. Ну и важно обсудить тайм-ауты. Тайм-ауты для клиента должны быть короче серверных, чтобы при ошибке сервера клиент мог запросить быстрее свою информацию. Безопасность. Всё чаще мы

252:40

Speaker A

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

252:55

Speaker A

мобильных разработчиков. Авторизация. Она может быть сделана на подходе OA2, либо же можно сделать кастомную авторизацию с двумя токенами.

253:05

Speaker A

Accessтокеном, его time to life 1-2 часа и рефреш токеном. Его time to life около 7 дней. Access toкеen позволяет нам обращаться к бэкэнду и получать данные.

253:14

Speaker A

Ну и refфреш toкенen позволяет нам обновить accessток и не просить пользователя ввести пароль. Это нужно для бешёвного обновления. Хранение акcessсса и рефреш токенов. Access токены хранятся в KY Story или Encrypted Shar Preferences для андроида. Ну а рефреш токены хранятся, скорее всего,

253:30

Speaker A

тоже в KAS Story или Encrypted Share Preferences. Важно, что мы никогда не должны их логировать, а также не хранить в незашифрованных хранилищах. Даже с наличием авторизации при работе с Senstitive данными нам всё равно может требоваться дополнительная авторизация.

253:43

Speaker A

Это двухфакторная аутентификация. Здесь у нас может использоваться либо пин-код, либо аналог биометрии, например, Face ID. Даже если пользователь прошёл двафа, нельзя забывать о том, что у нас может быть атака в виде in the middle, то есть данные могут перехватиться и

254:00

Speaker A

расшифроваться. Поэтому sensitive данные нужно подписывать. Подписывать ключами, которые мы, скорее всего, получаем из бэкэнда. После того, как вы всё обсудили, вам уже можно начинать строить вашу апи для бэкэнда. Собственно, можно выбрать какой-то протокол, описать и применить нужные конвенции надёжности и

254:17

Speaker A

безопасности и спроектировать ваши апи. что вы должны получить на выходе. Возможно, это будет некая моделька, где вы просто обсудите, что вы применяете.

254:26

Speaker A

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

254:45

Speaker A

конвенции. У вас есть ретра, когда вы получаете четырёхсотые или пятисотые ошибки. Также у вас есть для списков погинация, и она в виде курсорной либо daytтай погинации реализована. А также вы обсудили некоторые урезания ваших моделек либо thumbnails или фул картинок

255:04

Speaker A

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

255:13

Speaker A

Архитектура мобильного приложения. Это один из самых сложных и долгих пунктов на интервью, поэтому я представлю вам некую систему, по которой вы можете за пять шагов пройти от пустого листа к хорошей, классной архитектуре. Шаг первый. Выбор базовой архитектуры для

255:30

Speaker A

проекта нативе. Вы должны знать, а какой стек вы выберете и как именно вы построите вашу архитектуру. Например, для андроида я советую выбирать котlн крутины, трофиIT или окошTTP, возможно Corр. И для dependenнc инжекна можно выбрать Dagger 2 или Coin. Почему такой

255:46

Speaker A

стек? Потому что у него высокая востребованность на рынке. Это значит, что вы можете очень легко найти разработчиков на замену или на увеличение команды. А также он поддерживается углом и другими идущими компанией в разработке. Поэтому основывайтесь, наверное, от этого. Но

256:02

Speaker A

это база, от которой стоит отталкиваться. И всё же полностью понять, какой стек должен быть на проекте для проектирования, можно лишь задав некоторые вопросы интервьюеру.

256:10

Speaker A

Первый вопрос - это команда, насколько она большая и чем она владеет. Мы не можем выбирать технологию, которая популярна на рынке, если наша команда не умеет ей пользоваться. Цели продукта и Time to Markket. Если мы хотим быстрый рост, а также очень быстрый time to

256:26

Speaker A

market, то, скорее всего, наше приложение перестанет быть нативным, и мы будем его пилить на backend drive UI.

256:32

Speaker A

Также здесь важно обсудить, насколько часто мы хотим проводить а-тестирование и как именно мы хотим работать с фичфлагами, потому что от этого немножко изменится наша архитектура. Также стоит обсудить платформенную стратегию. Скорее всего, если вы будете проходить собеседование на Android или iOS

256:48

Speaker A

разработчика, то вы получите нативную стратегию. Но всё же вас могут попросить написать реализацию для кроссплатформенного приложения. И здесь уже нужно выбирать между cinplatform, React nativeвом или флатером. Далее стоит спросить про нефункциональные требования, такие как метрики, стабильности, crushшфри и всё в таком

257:07

Speaker A

духе. Опять же нужно продумать, как мы будем поддерживать всё это на этапе проектирования архитектуры приложения.

257:14

Speaker A

Для некоторых архитектур нам критично внедрение и влияние куркоманды. Например, мы не сможем построить хороший backend ring UI, если наша команда состоит из двух человек. Нам нужна инфраструктура. Поэтому, если она уже есть, если уже есть база, от которой мы

257:28

Speaker A

можем отталкиваться из других приложений, из других команд, из других компаний, то это будет хорошо. Здесь стоит обсудить, какие есть практики по CCD, по доставке нашей версии до пользователя и по тому, как мы будем взаимодействовать с бэкэндом. Приложение уже может иметь некое наследие. У нас

257:46

Speaker A

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

258:00

Speaker A

перекачевать sas в наше новое приложение. Для безопасности стоит обсудить, есть ли у нас sensitive данные и как мы будем их конкретно хранить. А также, чтобы наше приложение было успешным, нам нужно обсудить стоимость владения нашего приложения. Насколько мы хотим быть

258:15

Speaker A

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

258:32

Speaker A

опять же стоит задать вопросы, которые помогут вам решить, чему отдать предпочтение. Размер и рост команды.

258:38

Speaker A

Сколько разработчиков сейчас, а сколько будет через 6 и 12 месяцев? Многомотность отлично ложится, когда у нас больше пяти или семи разработчиков.

258:45

Speaker A

Параллельная работа. Если у нас практика работы над двумя фичами параллельная, и хотим ли мы сделать её удобной? А хотим ли мы ускориться на нашем MVP или мы можем немножко подождать для создания классной архитектуры для того, чтобы далее бежать быстрее? Скорость сборки.

259:03

Speaker A

Насколько нам критична скорость сборки, инкременная или холодная сборка? Опять же, если нам это всё критично, то многомоленность становится более хорошим выбором для большого приложения. Есть ли у нас разделения на фичи команды? И какие у нас границы доменов? границы

259:19

Speaker A

доменов и фича команды. Если у нас есть разделение на фич команды, например, главная, корзина и профиль, то контексты этих фичек-команд должны не пересекаться. Нам очень просто отделить их друг от друга, упаковав их код в модуле. Тем самым мы получим более

259:37

Speaker A

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

259:50

Speaker A

Готовы ли мы нести ответственность за соблюдение контрактов между фичами, контрактов их апимо модулей и имлмодулей? Какой долгосрочный план у наших модулей? Хотим ли мы выносить их как SDК для библиотек, либо мы просто их используем в приложении. Также можно

260:07

Speaker A

узнать про навигацию зависимости, тестируемость и стоимость владения. Теперь перейдём к тому, а что же представляет из себя монолит или многомодульность. Монолит - это когда у нас всего один модуль для приложения, это условно как один сервис.

260:23

Speaker A

Многомодульность же очень хорошо понимается словом микросервисы для бэкэнда, только это для мобилки. При работе в монолите мы можем достать любой класс из любого места, потому что мы не ограничены контрактами. Для этого нам всего лишь нужно поменять его приватность с, например, package private

260:41

Speaker A

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

260:58

Speaker A

выбирать фичемо модульную архитектуру. Это где мы выделяем фичмодули API Imp, а также core-модули тоже с API и частями.

261:07

Speaker A

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

261:25

Speaker A

самым мы ускорим процесс нашей сборки. Обсудим наши связи. Appмодуль зависит от всех модулей, потому что в итоге мы собираем именно app-модуль. Фичермодуль зависят на апе core-модулей и, соответственно, используют функционал нетворка авторизации навигации dependency инжекна или других кормодулей, которые мы выделяем между

261:46

Speaker A

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

262:03

Speaker A

от неё фичит пересобираться. Для того, чтобы правильно определиться в выборе архитектуры для проектирования, у нас есть некое простое правило. Для маленькой команды и быстрого старта и быстрой выкадки нашего MVP лучше использовать монолит. Если же мы хотим иметь некую большую масштатубируемость и

262:19

Speaker A

изменяемость, здесь стоит воспользоваться многомодностью. Шаг третий. Навигация без циклов. Для того, чтобы построить навигацию без циклов, можно воспользоваться созданием модуля Core Navigation. Мы будем навигироваться через плинки либо через интерфейс константы. Каждая фича реализует свой роутер и отдаёт его через

262:38

Speaker A

свой апи контракт. Ну и, соответственно, в другие фичи мы внедряем реализацию нашего роутера для навигации через Dependency Injection. Тем самым фичи знают контракт, получают реализацию через DI, но не зависит от реализации друг друга. Подробно рассмотрим архитектуру фичи. Как я уже говорил, мы

262:57

Speaker A

используем, а pattern, presentation, domain и data. Это clean архитек, а также внутри будем пользоваться MVM+ state. Здесь будет разобрана конкретная реализация для Андроида, но такую же реализацию можно сделать и на iOS. Для presentation слоя мы уделяем некий стейт, от которого будем отталкиваться.

263:16

Speaker A

Это базовая моделька нашего экрана, то, что мы показываем пользователю. State лежит в контроллере экрана. В нашем случае это вюмодель. Вьюшка или compс экран основывается на стейте и обsвит его. Ну а сама вмодель использует domain to vo mapper. Это некий мапер для того,

263:34

Speaker A

чтобы смапить модель из домена в наш statйтe. Команды и ивенты можно также завести, если нам это важно, либо можно просто вызывать функцию во вмодели.

263:43

Speaker A

Домен слой - это слой бизнес-логики, и от него никто не должен зависеть. От него зависит уже presentation и датаслои. Здесь у нас есть некиезкейсы.

263:52

Speaker A

Это пользовательские сценарии, действия, которые должно выполнять наше приложение. Нашизкейсы могут быть объединены в интеракторы либо действовать отдельно. Здесь всё зависит от политики того, как мы хотим с этим разбираться. Также как на презentation слое, мы выделяем некую доменную модельку для каждогойса или для каждого

264:11

Speaker A

экрана. Эта моделька обновляетсякейсом и отправляется дальше в Presentation слой. Также для того, чтобы домен не зависел от датаслоя, мы кладём в домен интерфейс репозитория. Мы применяем D изда.

264:28

Speaker A

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

264:45

Speaker A

выделяем модельку ДТО для работы с бэкэндом. Также для работы с кэшом мы должны выделить модельку Entity. В целом, если мы объединим наши три слоя, у нас получится Unidirectional Dataflow архитектура. То есть поток данных движется только в одну сторону от View к

265:00

Speaker A

VI-модели, от view модели к USйсу, далее в репозитории data store на backend. И по возвращении ответа с бэкэнда мы получаем ответы и движемся в обратную сторону. То есть мы просто заворачиваем.

265:10

Speaker A

Такой подход позволяет нам легче управлять данными. Мы можем легче изменять нашу архитектуру, масштабироваться, и у нас будет меньше лагов. Далее стоит обсудить некую надёжность и устойчивость нашей архитектуры, а именно реконнекты и резопросы, если что-то упало, переподключение к вебсокету или к другим

265:31

Speaker A

realта соединениям онлайн и оффлайн. хранение. И опять же глубоко копнуть в то, как будет устроена наша база данных для того, чтобы хранить наш кэш определённое время. Ну и тесты. В такой архитектуре фичи очень легко выделить тесты. Мы можем воспользоваться подходом

265:48

Speaker A

Humble Object, и наш контроллер или Viewмодель могут использовать внутри себя как многопоточку, так и разные зависимости на юкейсы. Но вся логика может выноситься в маперы, а уже маперы нам очень легко будет покрыть юнит-тестами. Аналогично можно поступить и для репозитория, либо просто покрыть

266:05

Speaker A

тестом репозиторий. Для UI скриншот-тестов или а-тестов или интеграционных тестов требуются отдельные доработки для того, чтобы они могли работать в нашей фиче. Поэтому стоит это обсудить с интервьюером. Ну и уже для НТНстов, скорее всего, нам потребуется не разработка, а

266:23

Speaker A

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

266:43

Speaker A

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

266:58

Speaker A

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

267:16

Speaker A

вместе с выбранным подходом налит или многомодульность. для многомодульности выдели фича Coreмо и расскажи про AP и ImpЛ подход. Ну и четвёртое, проверь то, что сделал архитектуру правильно и она удовлетворяет функциональным и нефункциональным требованиям, а также презентую интервьюеру. Часть четвёртая.

267:35

Speaker A

Кросплатформа и Backend Driving UI. Здесь мы поговорим о том, как правильно собрать приложение для удешевления разработки, а также для ускорения разработки. Удешевление разработки.

267:47

Speaker A

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

268:03

Speaker A

Андроиде, Айосе нарисуют нам разные реализации. Так, наши presentation даты и domain слои переносятся в некий shретмодуль. Далее мы просто обращаясь к движкам на Android, а IOS, рисуем разный UI. В принципе, так работает Cotlin Multiplatform и другие кроссплатформные фреймворки. У кроссплатформы есть

268:21

Speaker A

проблемы, которые я бы хотел обсудить. Во-первых, разные платформы - это разные подходы к дизайну, разные подходы к гайдлайнам наших вьюшек и, соответственно, к согласованности нашего Uикса. Поэтому нам нужно явно проработать то, как будут выглядеть две наши платформы и насколько они будут

268:38

Speaker A

одинаковые, где у нас будет различия. Для расследования ошибок приходится подключать разработчиков, которые больше специфицируются на Андроиде или на Айосе. Поэтому наша команда не может состоять из разработчиков одного стека, если мы хотим построить классное развивающееся приложение. Ну и поддержка

268:52

Speaker A

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

269:05

Speaker A

Удешевление разработки может и не сыграть, если мы неправильно работаем с кроссплатформой, но всё же самая главная проблема мобилок - это Time to Market. И здесь нам нужно ускорить нашу разработку, а именно ускорить выкладку фичи. Давайте сравним Time to Market на

269:19

Speaker A

backend Drive UI и нативе. Фича, которая делалась 4 недели чистой разработки и тестирования, выкатывается нативе через 42 дня, а фича на backend Driven UI через 32 дня. Казалось бы, разница не очень большая, всего лишь где-то 25%, но если мы перейдём к фиче, которое

269:35

Speaker A

делается 2 недели, то разница будет уже колоссальная. Вместо 28 дней нативе мы получаем 16 дней на Driven UI. Это практически в два раза быстрее. Почему же time to market bdui так хорош? В принципе, мы можем воспользоваться тем же подходом и только вместо shed модуля

269:52

Speaker A

у нас будет BDUI, который также будет иметь в себе presentation, domain, датаслои и отправлять нам на наши клиенты а какие-то вьюшки, которые мы уже будем рисовать нативно. Идеальный мир BDUя. Для BDUI мы можем воспользоваться курсподформностью и писать примерно в два раза меньше кода.

270:09

Speaker A

Наши даты domain и presentation на бэкэнде позволяют нам не писать код или практически не писать код на мобильные системы. И поэтому релизы у нас будут тоже на бэкэнде, и, соответственно, пользователи будут получать наше обновления сильно раньше конкурентов. Ну

270:24

Speaker A

и, в принципе, это новая технология, поэтому можно протоптать себе дорожку на конференции, выступления, либо стать амбассадором этой практики. Разберём, как реализовать идеальный мир BDUя. Это уже работающее приложение, и можно основываться на этом подходе. Во-первых, нам нужен курс платформный UI framework,

270:42

Speaker A

который будет рисовать наши вюшки. Можно воспользоваться дивкитом от Яндекса. Это open source решение, которое позволяет нам рисовать сразу же Android, iOS веб-версию. На Андроиде это View. Сейчас у них переход на comp и, возможно, даже есть поддержка флатера, но это не точно.

270:58

Speaker A

Как он работает? У нас есть некая вёрстка, которую мы пишем в декларативном режиме. Мы пишем её на котлине, и, скорее всего, у нас будет своя дэслька для того, чтобы нам удобнее её писать. В принципе, это очень похоже на декларативные фреймворки на Андроиде

271:12

Speaker A

и на Айосе. А поэтому разработчики очень быстро могут с этим разобраться. У нас есть источники данных на нашем BDUе. Мы пишем шаблоны для вёрстки и получаем некий Jon объект с уже всеми возможными картинками полями названиями которые отправляются нам на клиента. Уже на

271:30

Speaker A

клиенте движок дивкита рисует нативно все наши экраны. Естественно, нам нужен некий mobile app. Это эээнд, на котором будет лежать наш divкиit, который будет связываться с нашим приложением и отправлять нам а эти самые вьюшки.

271:45

Speaker A

Скорее всего, мы хотим, чтобы ээкэнд писался либо эээнд-разработчиками, либо mobile-разработчиками. Лично у меня была практика, что эээнд мы писали мобильными разработчиками, и именно поэтому мы выбрали подход, что эээнд был на котлине. Как он работает? А в целом вносится вся логика по хождению в разные

272:03

Speaker A

бэкэнды. Собираются все данные, как и на мобилке. Далее эти данные процессятся, создаётся divit вьюшка и отправляется нам на клиента. Также меняется код на клиентах. Вместо presentation domain и датачасти, которые мы обсуждали ранее, у нас остаётся лишь экран, который просто

272:20

Speaker A

вызывает один endpint с нашим bdм и после чего отрисовывает всё, что нужно. Ну, также, естественно, нужно подумать о шиммерах и скелетонах. И опять же всё это есть в нашем BDUе. Для того, чтобы поддерживать кастомные экшены пользователя по типу клика на кнопку

272:36

Speaker A

открытия ботом счета, нам уже хватит дивкита. Но что, если мы хотим добавить что-то своё? Добавить свои экшены, которые также могут обрабатываться и действовать как нам хочется. Для этого мы можем докинуть в наш BDU SDK помимо дифкита ещё и обработочки экшенов,

272:55

Speaker A

которые мы будем передавать с помощью нашего ответа от сервера. Ну и, собственно, наш BD SDK будет в себя включать нативный движок для дивкета, ну и некую имплементацию наших экшенов. Мы будем их находить по имени и выполнять, если мы нажали на кнопку и получили этот

273:12

Speaker A

экшн. Также многие экраны у нас содержат некий стейт, и этот стейт может со временем меняться. Если стейт экрана независим, он не меняется, то нам хватит и текущей реализации. Но если стейт экрана зависит от стейта ботом счета или что-то в таком духе, например, если у

273:29

Speaker A

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

273:44

Speaker A

далее этот стейт отправляется всем другим экранам. Второй пример, который также должен поддерживать общий стейт - это общая корзина в приложении. Корзина должна отслеживаться для того, чтобы показывать в ботом нафбаре количество элементов в корзине. Корзина должна меняться от нажатия на кнопку корзину на

274:03

Speaker A

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

274:15

Speaker A

Для этого можно воспользоваться неким Jon стейтом. это стейт, который будет храниться локально. Он может либо кашироваться, либо отправляться постоянно на ээкэнд. Вот. Ну, в общем и целом, а, мы управляем стейтом с бэкэнда. Для того, чтобы управлять стейтом с бэкэнда, нам нужно, чтобы мы

274:31

Speaker A

поддерживали интерпретируемый код. И как раз-таки в нашем BDUI подходе мы можем с бэкэнда отправлять интерпретируемый код, например, в джаваскрипте на клиента.

274:41

Speaker A

Компилируемый код, к сожалению, мы не можем отправлять. Это прописано в политике Apple и Google, поэтому мы можем остановиться на интерпретируемом подходе. Итак, что же может наш JSON state? Как я уже говорил, мы можем сохранить state локально, и это у нас

274:55

Speaker A

будет некий single state of true. Дальше мы можем отправить наш state на backend и отправить его каждый раз, тем самым меняя ат влияя на бизнес-логику дальнейших обработчиков на бэкэнде. А также мы обязательно должны быть синхронизированы с нашим дифкитом. Тем самым state может

275:13

Speaker A

быть неким obsрve стейтом для нашего Uая. UI будет обновляться при обновлении стейта, но с BDU не стоит играть. У BDUI есть огромный потенциал, но есть некие ограничения, а мы не можем менять домен.

275:29

Speaker A

То есть мы не можем сделать приложение, которое, например, доит коров, а затем при входе пользователя перекидывать его на банк. Скорее всего, в таком подходе мы будем удалены из стора, поэтому этим не стоит злоупотреблять и в особенность не стоит злоупотреблять возможностью

275:44

Speaker A

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

276:01

Speaker A

будет отвечать требованиям по UX, UАю, скорости работы. и так далее для пользователя. Поэтому первым этапом я предлагаю вынести доме и датаслои на бэкэнд-части и оставить на кле частях только presentation. Тем самым мы сможем понять, насколько выгодно или невыгодно

276:18

Speaker A

нам писать код на бэкэнде, а также при изменении а нашей домен и датамоделик мы можем управлять нашим клиентом автоматически. Скорее всего, это можно сделать, используя те же самые подходы по БФФу, но это уже немножко другое, потому что стейкхолдерами Bendri UI

276:36

Speaker A

всё-таки являются мобильные разработчики. На второй и отерации мы уже вносим и presentation часть на backend, проверяя наш U framework. И тем самым мы смотрим опять же на те метрики скорости, метрики счастья пользователя, которые у нас есть. Переводим лишь один

276:49

Speaker A

или два экрана на Pendri UI и затем, получая отклик от пользователей, понимаем, нужно нам это или нет. Ну и после того, как мы поняли, что BDUI нас устраивает, что нам очень хочется катить эксперименты быстрее в два раза, чем мы

277:00

Speaker A

это делали на Нативе, мы можем полностью переходить на Bкend Driven UI. Но BDUI - это далеко не идеальная технология. У этого подхода есть множество проблем. Я расскажу о них. А первая проблема то, что у нас есть много запросов.

277:13

Speaker A

Во-первых, мы добавляем новый ээкэнд, который ходит в те же старые бэкэнды, как ходила наша мобилка. Так ещё и мы постоянно для любого обновления должны ходить на этот бэкэнд. Получается, если нам нужны какие-то realtтай обновления, то довольно сложно это реализовать с

277:24

Speaker A

помощью BDUIя. Вторая проблема есть и при переходе на крсплатформу - это обучение iOS и Androidразработчиков.

277:30

Speaker A

Если мы выбираем, например, BDUI на декете иэнд на котлине, то, допустим, Android-разработчикам будет довольно легко на это перейти. Они уже знают котlн иIT очень похож на ту технологию, на которой они, скорее всего, пишут UI.

277:45

Speaker A

iOS разработчиком будет сложнее, потому что незнакомы с котлиным, незнакомы со средой разработки Intellig ID, и в принципе это не особо сильно им нужно.

277:54

Speaker A

Также у нас присутствуют различные проблемы, о которых я говорил про курсплатформу. Например, вьюшка с Match Parent и Wrap Content при изменении этих параметров и вложности крашится на Айосе, но хорошо отображается на Андроиде. Таких проблем будет масса, и нужно быть готовым к тому, что у вас

278:12

Speaker A

должен быть какой-то разработчик из коркоманды, который будет постоянно отвечать на все вопросы и чинить всем ребятам проблемы. Также у нас есть ээ большой риск с персоналом. Например, у нас есть iOS разработчик Стив. Ему 26 лет, а он закончил университет, и он

278:28

Speaker A

находится на городе Middle или middle п он хочет расти дальше, ему нравится Swift и нравится веразработка.

278:34

Speaker A

Представим, что вы как руководитель предлагаете ему перейти в команду для построения кэня, говоря о том, что за этой технологией будущее. Ведь этой технологией пользуются такие крупные компании, как Can, Яндекс, Альфабанк и так далее. Но Стив-то хочет сейчас получить

278:52

Speaker A

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

279:06

Speaker A

Лично у меня такой проблемы не было, потому что я Android-разработчик, но я спросил у айосеров специально для этого видео, на что мне сказали, что ребятам было очень интересно, что это такое. А также из-за того, что CotL Multiplatform становится всё более и более популярным,

279:19

Speaker A

всё-таки изучение котлина - это хороший поинт и хороший булит для резюме. Также на BDUАе довольно сложно сверстать экраны со сложным стейтом, со стейтом, который постоянно меняется. Допустим, у нас есть некая воронка для пользователей с таймером для того, чтобы показать им

279:37

Speaker A

какую-то очень классную акцию. Например, LEGO за 10 руб. Если же у нас таймер при начале нашей акции залагал и наши пользователи не увидели отсчёт или наоборот при окончании таймера и их добавлении в некий пул покупателей, опять же залагал таймер, мы получим

279:53

Speaker A

пултуре refфреш для всех, допустим, 100.000 пользователей, а это означает, что это 100.000 RPS, а это, скорее всего, положит наш бэкэнд. Далее у нас есть работа с видео. Здесь в целом мы тоже не особо вальны конфигурировать то, как мы с ним работаем, потому что

280:09

Speaker A

работает со стандартными инструментами для Андроида и для iOS. Поэтому, если ты проектируешь какой-то крупный видеохостинг, которому необходимо иметь кастомные методы воспроизведения видео для экрана, то BDUI - это не твой подход или, по крайней мере, подход не для этого экрана конкретно. Также у нас есть

280:25

Speaker A

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

280:41

Speaker A

доработками на BDUе на некий стенд, который должен быть некой виртуальной машиной на твоём компьютере либо на стенде компьютера в вашей компании, и только там ваши тестировщики смогут протестировать ваши доработки. дизайнсистема.

280:57

Speaker A

Если у вас уже была дизайн-система, на которой вы работали, то для BDU вам стоит проработать её заново либо сделать её ещё раз. Ну и релизы. Если ранее у вас было всего лишь два релиза и ваше тестирование уходило на регресс один раз

281:13

Speaker A

в неделю, то сейчас помимо того, что у вас есть релизы приложений, у вас также добавляется релиз вашего BDUя как энд аппликейшна, который случается довольно часто, допустим, каждый день для того, чтобы поддерживать высокую скорость а раскатки. Также у вас

281:29

Speaker A

появляются библиотеки, например, BDUI SDK, которые тоже требуется обновления. И каждое добавление нового экшена триггерит на новый релиз. Поэтому, если раньше у вас было два релиза или два регресса, сейчас эта цифра растёт до пяти или восьми. Ну и по трудозатратам

281:46

Speaker A

на релизный процесс вы растёте от 60 до 120 человек часов. Ну и самая последняя проблема, которая, возможно, и не является проблемой - это своя технология. Раньше вы могли спросить у Chat GPT, обратиться в Google, перейти на Steck Overflow, но сейчас

282:00

Speaker A

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

282:20

Speaker A

подведём итоги. Нужна ли нам в итоге кроссплатформа или нет? А нужен ли нам BTUI или нет? Всё, конечно же, зависит от бизнеса. Если мы хотим быстрые релизы, быструю скорость для фиксов, а также хотим а какую-то классную курсплатформу, то, скорее всего, лучше

282:35

Speaker A

выбрать BDUI и плавно на него перейти. Из плюсов у нас будет высокая скорость разработки, высокая скорость изменчивости, а большая скорость фиксов, потому что мы сможем не только фичуфлагами нашу фичу вырубать, но и менять нашу фичу прямо на бэкнде за 1-2

282:52

Speaker A

дня и не ждать целую неделю. А также пользователям не нужно будет обновлять новую версию приложения, если мы всё сможем поменять на бэкэнде для уже существующего экрана. Ну, а также у нас есть возможность сразу же сделать нам кросс-поплатформу для того, чтобы наши

283:06

Speaker A

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

283:30

Speaker A

согласовывать с UI и UX-дизайнерами то, как у нас будет выглядеть UI. мы не сможем сделать всё приложение на BDU, потому что у нас всегда будут сложные состояния, видео и так далее. И всё-таки эти части лучше делать нативно. Ну а

283:46

Speaker A

также мы упираемся в то, что у нас есть iOS-разработчики и тестировщики, которым будет очень тяжело перейти к новому подходу. Разработчикам стоит учить язык, а тестированию нужно будет менять подход pйплаine и то, как они тестируют. В принципе, поработав на BDЮае и поработав

284:02

Speaker A

на Нативе, я могу сказать, что, в принципе, оба подхода хороши для своих задач. Мне было интересно работать на BDI подходе, но так как я столкнулся с вот вышеперечисленными сложностями, сейчас мне больше нравится разрабатывать нативе, потому что всё-таки на Нативе у

284:17

Speaker A

нас сложностей сильно меньше. Но мы за это жертвуем релизами, скоростью разработки и ценой разработки. Для систем дизайна, если вы выбираете подход вя, скорее всего, стоит нарисовать верхнеюуровневую диаграмму, а также внутри пояснить за то, как будут действовать и как будут связаны ваши

284:35

Speaker A

компоненты. Далее стоит очень хорошо проработать то, как и кто будет реализовывать вашу BDI систему, её курчасть и как она будет работать. Также стоит рассказать про все минусы и плюсы BDUя, о которых я говорил ранее. А теперь переходим к домашнему заданию для

284:52

Speaker A

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

285:08

Speaker A

Задача: нужно спроектировать приложение для акций. У нас доступны четыре бэкэнда. Это бэкэнд для аутентификации, бэкэнд для push уведомлений. Мы будем делать кастомные пуш-уведомления, чтобы они работали во всех регионах России.

285:22

Speaker A

Также нам нужно спроектировать контракты для бэкэнда Real time для того, чтобы получать акции с задержкой не более 3 секунд. Также нам нужно спроектировать эээнд для детальной информации об акции, например, о том, как основали компанию, кто её основал и о её истории. Пока что

285:40

Speaker A

приложение MVP, поэтому мы даём возможность пользователям только просматривать акции. И для премиум пользователей в pushшнотифиicкейшнсах мы будем говорить об инсайдах, которые мы знаем, для того, чтобы наши пользователи в других приложениях смогли купить классные акции. Команда состоит из десяти разработчиков midлle и senior

285:57

Speaker A

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

286:14

Speaker A

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

286:32

Speaker A

акций. Было четыре бэкэнда, которые делали разные действия, а также была возможность использовать любые технологии для нашей команды из десяти разработчиков. Нужно было спроектировать апи, архитектуру приложения и архитектуру фичи просмотра акций. У accessтокена to life 1-2 часа, у рефреш

286:51

Speaker A

токена 7 дней. Ну и, соответственно, мы а не заставляем пользователя вводить пароль каждый раз, когда accessтокеen протухает, потому что у нас есть достаточно большой рефреш токен для обновления нашего accessтокена. Для пуш-нотификаций можно использовать Minbox или Firebase. Mindbox доступен на

287:07

Speaker A

всей территории России, и можно сделать его достаточно легко. Там просто нужно по его апе реализовать сервис. Далее, для просмотра акций и их котировок нам нужен сокет. Я бы выбрал здесь вебсокет, потому что в будущем мы, скорее всего, захотим продавать и покупать акции. И

287:26

Speaker A

именно поэтому нам нужно будет уметь отправлять сообщения. Поэтому здесь я бы заложил архитектуру на будущее. Если же этого не предвидится и вам интервьюр явно говорит об этом, то можно выбрать сервис Sent Events для того, чтобы обеспечить однодуплексное соединение. Ну а наш кэнд акций может

287:42

Speaker A

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

288:02

Speaker A

пришла к тому, где она есть сейчас. Это Rest AP, и здесь простые get запросы. По поводу политики, надёжности, конвенции и траев. Для вебсокета я бы выбрал переподключение с экспоненциальным временем для того, чтобы если у клиента или у сервера неполадки, мы постоянно не

288:18

Speaker A

додосили бкэнд. Для REST IP я бы выбрал кнопку Повторить, где мы просто траем запрос. Аналогично для того, чтобы отрисовать ошибки, мы можем использовать и кнопочку повторить на авторизации и логине. Ну а для пушей, в принципе, ничего, наверное, и не стоит делать.

288:36

Speaker A

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

288:53

Speaker A

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

289:04

Speaker A

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

289:24

Speaker A

профиль, нам можно разделить на фичмодульную архитектуру нашего приложения и использовать многомодульность. Для фичей я бы выбрал апи и подход, так же как и для core-модулей. Фичи будут зависеть на свои апимодули, а также на апимодули других фичей для навигации. Ну и,

289:42

Speaker A

собственно, подход с роутером мы берём прямо из этого видео. Core-части мы выделяем Core Network, Core Navigation, Core UI и Coreills модули. А database модуль, а, возможно, мы выделяем, а возможно, нет. Это всё зависит от того, чтобы сказали вам на интервью. Если

289:58

Speaker A

нужно кэширование, то выделяем. Но в нашей задаче из-за того, что нам важны очень котировки акций, и нам важно, чтобы они обновлялись не позже, чем через 3 секунды, скорее всего, кэш нам не нужен. Давайте перейдём к детальному рассмотрению нашей фичи, именно

290:15

Speaker A

детальной акции. Здесь я выделяю модельки для каждого из слоёв для того, чтобы мне было удобно, а, с ними работать, чтобы они были независимы и чтобы абстракции у меня не перетекали из слоя в слой. У меня есть view-модель как

290:29

Speaker A

контроллер в presentation слое, и она содержит модельку. Вьюшка передаёт вмодельке ивенты на все нажатия пользователя, а Vмодель либо обновляет сreateт, учитывая работу с бэкэндом, либо же отдаёт какие-то команды вюшке для того, чтобы вюшка сделала действие, например, снавигировалась. Также мой

290:49

Speaker A

view object или Screen State собирается с помощью мапера, на который я напишу тест. И здесь воспользуюсь подходом Humble Object. Доменчасть довольно простая. Здесь утюзкейсы для получения детальной акции и для подключения к бэкэнду по вебсокету для того, чтобы получать котировки акций. Также будет

291:08

Speaker A

репозиторий, который будет всё это выполнять. А уже реализация репозитория будет в дата-части. Здесь мы используем паттерн dependency inversion из Solida.

291:17

Speaker A

Для даты здесь я решил нарисовать полную логику вместе с кэшом для того, чтобы просто показать, как это выглядит. В КШ мы будем хранить деталку для нашей акции. То есть это информация, которая меняется очень редко. Котировки акции мы в кше не будем хранить. Соответственно,

291:32

Speaker A

у нас есть две модельки в этой части. Это то для общения с бэкэндами и entтити для общения с базой данных. В этой части основным действующим лицом является репозиторий, а также data source, который может входить либо в локальный, а data store, либо в remote data store.

291:50

Speaker A

Наш репозиторий использует маперы для того, чтобы преобразовывать дтолошки в entти и отправлять их через data source в хранилище. Также он основывается на том, что уже есть в хранилище, и и хранит expire Time для того, чтобы обновлять или очищать кэш по мере его

292:10

Speaker A

устревания. Ну и также на мап с ДТО в домен у меня написан тест для того, чтобы наша логика была протестирована.

292:19

Speaker A

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

292:35

Speaker A

систем-дизайну для мобильного разработчика, как проектировать апи, как проектировать приложение и что же такое за подход backend Driving UI и когда его стоит применять. Желаю вам удачи на полях сражений, то есть на интервью, а также поскорее становитесь синьорами и

292:51

Speaker A

синьорками. Спасибо. Хотя интервью по системному дизайну обычно относят к техническим, его очень легко слить по причине того, что нету чёткого регламентированного, правильного ответа на поставленные вопросы. Здесь важно не только то, как ты построишь систему, но и то, как ты к этому решению

293:15

Speaker A

придёшь, насколько системно ты умеешь мыслить и как ты умеешь аргументировать и доказывать необходимость выбранных инструментов. Само собеседование предполагает проектирование полной системы или её отдельной части. Тебя могут попросить спроектировать eBay или систему рекомендаций на YouTube. Зависит от профиля компании, нанимающего

293:36

Speaker A

менеджера или просто настроение интервьюевера с утра. Чтобы успешно пройти этот этап и максимально показать все свои знания, тебе нужно соблюдать чёткую структуру ответа. Это немного напоминает поведенческое интервью, где тебя как бы спрашивают общий вопрос, типа, расскажите про свой провал. Но на

293:54

Speaker A

самом деле предполагается, что ты будешь отвечать на этот вопрос по структуре Star. Ну, про это речь пойдёт в каком-нибудь другом гайде. А сейчас обратно системдизаignн. Во-первых, ты будешь ограничен во времени. У тебя будет не больше часа от начала интервью

294:10

Speaker A

до его завершения. Во-вторых, как я уже сказал, интервьюр будет обращать внимание на то, как ты умеешь системно мыслить, способен ли ты спроектировать систему самостоятельно и аргументировать принятые решения. Короче, залететь на созвон, 40 минут молчать и потом сказать: "Ну вот, готово, не прокатит".

294:29

Speaker A

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

294:40

Speaker A

Как ты уже знаешь, требования делятся на функциональные и нефункциональные. Чтобы выявить функциональные требования, тебе, как ни странно, придётся задавать вопросы, касающиеся функционала будущей системы. Например, какие роли будут у пользователей в системе? Какие действия может совершить пользователь в определённой роли на сайте? Как работает

295:02

Speaker A

поиск и что от него ожидается? Какие способы оплаты поддерживает система? Если опираться на возможные ответы на эти вопросы, функциональные требования к системе будут выглядеть вот так. Должны быть роли администратора, продавца, покупателя, модератора. Пользователь в роли покупателя может сменить пароль и

295:20

Speaker A

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

295:37

Speaker A

Нефункциональные требования касаются непосредственно характеристик системы. Нам обязательно нужно уточнить следующие вопросы. DAO и MAO нужны для расчёта RPS. DAO и МA дают средние значения, но системы проектируют под пиковую нагрузку. Обязательно нужно спросить: в какое время суток, года нагрузка

295:57

Speaker A

максимальна? Во сколько раз пик превышает среднюю? Например, для мессенджера пик будет вечером, для eBay в чёрную пятницу. Скорости роста объёма данных. Количество пользователей через N лет. Это нужно для расчёта объёма хранимых данных и дальнейшего масштабирования. Размер загружаемых данных, будет это видос на терабайт или

296:20

Speaker A

картинка с максимальным размером мегабайт. Это нужно для выбора хранилища данных, протокола обмена и дополнительных расчётов. Соотношение записей и чтение данных нужно для выбора хранилища и разделения потоков данных.

296:34

Speaker A

Длительность хранения этих данных нужно опять же для выбора хранилища и протокола обмена. Нефункциональные требования могут выглядеть так: DAУ 1 млн, МАУ 10 млн. Прогноз через 5 лет МАУ 100 млн. Одно изображение максимально 3 Мб. Один пользователь в среднем четыре

296:53

Speaker A

чтения и одна запись в день. 80% запросов на чтение, 20% запросов на запись 1 год. Именно функциональные и нефункциональные требования системы результат твоей работы на этом этапе сбора данных. Теперь тебе нужно провести все расчёты по твоей системе. Добиваться

297:12

Speaker A

точных результатов здесь не нужно. Они могут быть приблизительными. Важен порядок расчётов. Идеально, если на собеседовании можно использовать калькулятор. Когда я говорю о приблизительных расчётах, я имею в виду, что, например, среднее число дней в месяце 30,44.

297:30

Speaker A

Но здесь будет нормально допустить, что среднее число дней - это 30. Главная цель расчётов не получить точное число, а понять, насколько система большая. Нам нужно 10 серверов или 10.000. Определить критические компоненты. Например, расчёты показали, что трафик гигантский.

297:47

Speaker A

Значит, нам нужен агрессивный кэш и CDN. Или мы видим очень большой объём данных. Это значит, нам нужно шардирование с самого начало. И, наконец, обосновать свои архитектурные решения и подкрепить их расчётами. Тут тебе могут помочь готовые таблицы для работы со степенями.

298:05

Speaker A

Ну и стоит запомнить, что 10 вше степени - это мегаб, а 10 в - это гигай. Есть и другие полезные таблицы, например, таблица Latency или SLA. Требования по SLA встречаются не всегда, но опять же лучше иметь эту таблицу под рукой. Это

298:21

Speaker A

абсолютно нормально и не будет засчитано как списывание. Результат работы на этом этапе- расчёты твоей системы, которые зафиксированы письменно и устно.

298:32

Speaker A

Скорость роста объёма данных, общий объём хранимых данных, RPS и всё остальное, что нужно для проектирования твоей системы. Третий этап - домены и API. На этом этапе ты выписываешь все сущности, которые участвуют в твоей системе, и вместе с интервьюевером

298:48

Speaker A

определяешь, какие из них в текущую задачу не входят. В случае с условным eBay это может быть продавец, покупатель, добавление объявления, система поиска по ним и так далее. Здесь важно обозначить связь между сущностями.

299:02

Speaker A

Далее предстоит перейти к проектированию АИ. Как я упоминал ранее, здесь нужно объяснить свой выбор. Например, ты выбрал Рестапи из-за лёгкости тестирования и удобства интеграции с другими платформами или, наоборот, выбрал граф QL ради гибкости.

299:18

Speaker A

После этого нужно перейти к описанию Апи применительно к каждому домену, который участвует в системе. Здесь также не требуется углубляться в детали. Важен общий ход твоих мыслей. Однако интервьюер может попросить подробнее расписать то или иное решение. Четвёртый этап - highlevel design. И вот здесь уже

299:36

Speaker A

нужно нарисовать саму архитектуру системы. Не углубляйтесь в детали. Вам нужно успеть закончить схему всей системы и доказать, что она работает. На экране ты можешь увидеть пример верхнеуровневой архитектуры индийской платёжной системы. Что-то вроде нашей системы Мир. Какой вывод можно сделать

299:54

Speaker A

из этой схемы? Самый простой способ начинать от пользователя. Подписанные стрелки упрощают восприятие системы. Не нужно городить дата-центры. На этом этапе можно сделать допущение, что он один. Но мы помним, что для масштабирования и отказоустойчивости можно использовать технику multiployment.

300:16

Speaker A

Лучше избегать циклических связей. Пятый этап - low level design. Теперь нам предстоит пройтись по созданной архитектуре и определиться с конкретными решениями для созданных компонентов. Не забывайте говорить, не стоит, как безумные учёные чертить стрелки и приговаривая: "Сча, сейчас, сейчас

300:34

Speaker A

будет, сейчас дорисую, всё поймёте". Нужно показывать ход своих мыслей и рассуждать, объяснить, почему выбрано конкретно такое решение, какие у него преимущества и недостатки, какие альтернативы мы отбросили. В идеале не только устно это проговаривать, но успевать делать короткие письменные

300:51

Speaker A

заметочки рядом с компонентами системы. ты можешь увидеть уже знакомую индийскую платёжную систему, но уже в low level дизайн. Я специально взял пример, где компонентов не так много, чтобы разница была очевидна. По сути, это та же самая схема, но в ней гораздо больше внимания

301:09

Speaker A

уделено деталям реализации внутри компонентов. Если ты корректно прошёлся по всем этапам, то в конце тебя ждёт несколько вопросов про твою систему, про стабильность, отказоустойчивость и масштабируемость. К этому моменту эти вопросы уже не должны тебя смущать.

301:25

Speaker A

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

301:43

Speaker A

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

301:58

Speaker A

Чтобы не допустить такой проблемы, рекомендую каждому перед походом на реальный рынок попросить у какого-нибудь товарища провести МОК интервью, где он будет выполнять роль такого сурового интервьювера, задавать вам вопросы провокационные и просить пояснить, почему эта система действительно будет работать. Смысл мог интервью многие не

302:19

Speaker A

понимают, говоря что-то типа: "Да нахера мне тренироваться? Я лучше на рынок пойду и там сразу пройду вот как бы в боевом опыте себя испытаю". Но проблема-то в том, что на рынке после интервью вам не присылают настолько подробный фидбэк и не подмечают ваши

302:35

Speaker A

косяки. Вам говорят что-то типа: "Мы решили продолжить с другим кандидатом" и вы остаётесь в неведении. А вы вообще правильно всё рассказали? Или были ошибки? Может быть, вы запороли? А может, вас интервьюер вообще не слушал?

302:46

Speaker A

Смысл мог интервью с каким-то родным, близким человеком как раз-таки в том, что он вам бескра скажет, где у вас косяки. Ну а если родного человека с достаточным уровнем экспертности для такой задачи нету, предлагаю воспользоваться нашим сервисом IT-менторы. Обязательно почитай

303:01

Speaker A

предварительно отзывы, выбери ментора себе по вкусу, пообщайся с ним и пройди этомок интервью. Можешь даже записать своё реальное интервью и попросить этого ментора его разобрать и вместе понять, где ты действуешь неэффективно.

303:18

Speaker A

Так как секция по системному дизайну достаточно сложная, кандидаты на ней часто спотыкаются, хотя кажется, что всё идёт нормально. Предлагаю здесь разобрать ошибки, которые встречаются особенно часто. Использование в архитектуре незнакомых технологий. На этапе lло lowлевеel дизайна тебе в той

303:37

Speaker A

или иной мере придётся объяснять, как работает каждый компонент. Если ты упомянул кавку, будь готов пояснить, чем она лучше, чем Rabbit MQ. Если с технологией ты знаком на уровне, что-то слышал, чуть-чуть читал, добавлю в резюме, здесь, скорее всего, это и

303:53

Speaker A

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

304:09

Speaker A

Пускай даже она звучит как-то не очень круто. Тогда ты сможешь нормально пояснить, а почему именно такое решение.

304:16

Speaker A

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

304:27

Speaker A

Зачем прикладывать усилия, которые могут не окупиться? Но у такого подхода есть минус. Без практики очень трудно понять, зачем нужен тот или иной этап. На самом деле, например, ты послушал меня и пошёл спрашивать: "А сколько планируются пользователей через 5 лет?" И тут может

304:43

Speaker A

быть две проблемы. Во-первых, проект вообще не рассчитан на долгосрок. Во-вторых, эти числа так и останутся в графе функциональные требования.

304:52

Speaker A

Поэтому, когда в начале ролика я просил тебя подумать над сбором требований для онлайн-сервиса Выгула котов, крайне важно было проделать это упражнение.

305:02

Speaker A

Во-первых, важны вопросы, которые ты задаёшь. Во-вторых, важно, зачем ты их задаёшь. Я предлагаю тебе выполнить ещё одно упражнение в рамках этого примера.

305:12

Speaker A

Допустим, ты спрашиваешь меня: "А сколько в среднем котов на одного платящего пользователя?" И я отвечаю: "Зачем тебе нужны эти данные? Твоя задача - выписать все метрики и задачи, для которых тебе эти данные понадобятся.

305:27

Speaker A

Строительство космолёта". Сюда помещается сразу несколько ошибок. Во-первых, попытка рассказать вообще всё, что знаешь про архитектуру и системы. Во-вторых, расширение системы за рамки обозначенной задачи. Попытка за час спроектировать сервис, который перевернёт мир. В первом случае помогут как раз тренировочные собесы. Там ты

305:48

Speaker A

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

306:05

Speaker A

время на проектирование лишних компонентов. Ну а третье, наверняка тебя хоть раз попросят спроектировать Google или там свою собственную Chatт GPT на сабесе у какого-нибудь ИПэшника. Но я прошу тебя помнить про ограничения в реализации. У большинства компаний нету триллионов денег на их проекты. Они

306:26

Speaker A

просто хотят, чтобы система работала и стабильно приносила деньги. Поэтому, если ты понимаешь несоразмерность требования и компании, лишний раз аккуратно уточни, а сколько там у нас вообще бюджета и точно ли мы хотим делать новый поисковик убийцу Гугла? На тему третьей ошибки хочу поделиться

306:45

Speaker A

личным кейсом. Когда-то очень давно, ещё имея там год опыта в iё разработки, я поехал на оффлайнсобеседование в офис.

306:52

Speaker A

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

307:09

Speaker A

вот так вот ноутбук, там открыт Adobe Илustratтор, кто знает. Ну, короче, это не та программа, в которой сейчас принято проектировать интерфейсы приложений. там какой-то дизайн какой-то, ээ, приложение. И мне говорят: "Вот слушай, давай-ка ты быстренько нам раскидаешь, за сколько и как ты бы это

307:28

Speaker A

сделал?" И мой мозг закручивается, начинает разгоняться. Я думаю: "Блин, тут ты что? И в какой-то момент я просто себя выдёргиваю и думаю: "Ну, это явно же мы занимаемся точно не тем". Меня просят на Сабесе там за полчаса проанализировать

307:43

Speaker A

по скриншотам экранов какое-то приложение, дать какие-то сроки, какие-то бабки назвать. Я говорю: "Ну, мужики, извините, это так не делается.

307:51

Speaker A

Как бы если вы хотите нормально пособеседоваться, давайте обсудим". Но я, наверное, не могу ответить. Мне на это нужно там день два-три. Но потом меня спросили, сколько бы я хотел денег в месяц. Я назвал цифру, дизайнер обиделся, захлопнул крышку ноутбука, сел

308:06

Speaker A

вот так и сказал: "У меня больше нет вопросов, и в этой компании я в итоге не поработал". Отказ от продуктовых метрик.

308:13

Speaker A

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

308:31

Speaker A

понимания бизнеса и продукта. Предполагается и ожидается продуктовое мышление. Разработчик, который мыслит и умеет опираться на продуктовые метрики при принятии решений, будет цениться бизнесом гораздо больше, чем вот, который Нет, вот у меня есть код, всё, я ничего не знаю, мне на пользователей

308:51

Speaker A

пофиг. На самом деле это, конечно, не все ошибки. Есть ещё ряд технических нюансов, а также советы типа "Не уходи чрезмерно в абстракции". Но всё это вытекает из предыдущих глав. Напиши в комментариях, какая из глав тебе была особенно интересна и полезна. И поставь

309:09

Speaker A

этому видео лайк. Да просто, чтобы мне было приятно. Также приветствуются любые вопросы. Мало ли, мы что-то забыли, с удовольствием на них ответим. Я надеюсь, что этот ролик был для тебя полезен, ты узнал что-то новое, и теперь будешь просто как нош сквозь масло проходить

309:26

Speaker A

через этап System Design и Intervw. У нас на канале планируется ещё много схожих образовательных видео. Будем планомерно закрывать все пробелы в техническом контенте, поэтому подписывайся, чтобы не пропустить новый контент. Большое спасибо за просмотр.

309:43

Speaker A

Это был Антон Назаров. И начни уже зарабатывать больше.

Topics: системный дизайн интервью Middle Plus архитектура ПО масштабируемость отказоустойчивость микросервисы техническое интервью Slack компенсации

Get More with the SozAI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries and speaker detection. 30 minutes free.

App Store Google Play

Or transcribe another YouTube video here →

Free tools: TXT to SRT · SRT Validator · Merge SRT · Subtitle to Text · All tools