System Design

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

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

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

В целом структура данного собеса одинаковая и для фронта, и для бэка, ниже кратко разберем её.

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

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

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

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

Что по фронту
Тут же начинаем с одного пользователя, а затем масштабируемся. Также стоит учитывать, что у юзеров может быть плохой инет, древний браузер и кирпич вместо телефона. Это тоже сильное влияет на итоговое решение. Что стоит обсудить на этой секции: контракт API, стратегия рендеринга (CSR / SSR / SSG, гидрация), работа с состоянием. Дальше - производительность (размер бандла, ленивая загрузка, и прочие вещи), UX-состояния, доступность и локализация. И только потом выбор методологии под проект и уже совсем в конце сами компоненты.

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

Что общего
И там, и там проверяют одно и то же: умеешь ли ты работать в условиях неопределённости, видишь ли компромиссы и можешь ли объяснить, почему выбрал именно это. Формулировка уровня «я взял такой подход из-за ограничения X, но если бы было условие Y — выбрал бы Z» показывает в тебе инженера.

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

Подписывайтесь на канал и вступайте в чатик, товарищи, так вы не пропустите новый контент!

Подписаться: @codeof_art