Mobile System Design — один из главных навыков мобильного инженера. В реальной практике или на собесе это определят твою сеньорность. Компании проводят секции с оценками. Указывают навык в матрице компетенций. Требуют от тебя выполнения плана на работе.

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

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

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

Содержание

Зачем это нужно?
Что такое Mobile System Design?
Заблуждения о Mobile System Design
Как проводят собесы компании
Как Mobile System Design помогает в реальной жизни
Разбор популярных задач
Выводы

Зачем это нужно?

Я проводил опрос среди подписчиков канала. Где 77% опрошенных ответили, что сеньор должен уметь решать и проектировать сложные и большие системы.

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

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

Что такое Mobile System Design?

Чтобы найти наиболее надёжный компромисс среди множества мнений и подходов, я решил объединить самые авторитетные источники из четырех разных миров:

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

Цель простая: выделить инварианты. Навыки, подходы и техники, которые ценны в любой компании, на любой платформе и при любом проекте. Отделив спорные и специфичные термины и критерии.

iOS System Design: Чем уникален мобильный систем дизайн

Мне нравится формулировка:

Mobile System Design — это умение превратить бизнес-требования в чёткий тех.план мобильного приложения: какие компоненты нужны, как они взаимодействуют и как обеспечить надёжность, скорость и гибкость кода. Ты получаешь требования — и решаешь, какие части системы нужно создать и как они будут работать вместе, чтобы решить задачу бизнеса @ Tjeerd in ’t Veen

Также можно для примера взять на матрицу компетенций Авито:

Что это нам говорит? В критериях можно подвести напрямую ключевые навыки сеньора в System Design'е:

Критерий E5	В System Design это проявляется так
Декомпозирует проблемы или бизнес-сценарии в решения из нескольких компонентов	Дробит фичу на модули, слои, API-контракты, источники данных
Локализует/предотвращает проблемы, даже если причина в другой команде	Проектирует изоляцию, graceful degradation, устойчивость фасадов
Работа с внешними зависимостями проекта	Учитывает ограничения бэкенда, дизайн API, версии, SLA, ретраи
Улучшает общие инженерные инструменты	Выбирает решения, повышающие скорость всей команды
Тестирует сложные корнер-кейсы	Заложена проверка ошибок сети, оффлайна, обновлений
Устанавливает нефункциональные требования	Думает о производительности, надёжности, безопасности
Использует безопасные подходы	Продумывает хранение и передачу данных, секреты, токены

Иначе говоря, сеньор — это человек который напрямую умеет:

Разрабатывать надежное и стабильное приложение
Глубоко и широко учитывает особенности мобильной разработки (сеть, память, батарея, устройства)
Умеет увеличивать эффетивность команды и даже компании
Может эффективно строить системы при этом четко отвечать бизнес-требованиям

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

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

https://www.youtube.com/watch?v=wq2IXwoxMk0

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

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

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

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

Заблуждения о Mobile System Design

В этой теме накопилось много мифов о которых я писал в начале.

Заблуждение № 1: Важно красиво нарисовать схему

Не редко встречал даже от тимлидов, что System Design — это рисовать квадратики и стрелочки. Чем детальнее диаграмма — тем выше уровень инженера. Но это не так. Цель секции не в том как красиво ты нарисуешь рисунок, а как вы собираете требования, расставляете приоритеты, принимаете компромиссы и планируете реализацию.

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

Заблуждение № 2: Важен лайфкодинг

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

Получается не оценка проектирования сложной фичи в сложной системе, а просто ещё один раунд лайфкодинга. Иногда HR даже присылают ссылки для подготовки по ARC, Generics и другим деталям языка — но всё это не имеет прямого отношения к целям секции.

Лайвкодинг нужен далеко не всегда, и точно не в центре оценки. На секции цель — это НЕ реализовать идеальное решение. На System Design важно не писать код, а объяснять, какой код стоит писать, зачем и нужно ли его вообще писать.

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

Заблуждение № 3: Нужно сразу выбрать самое сложное решение и глубоко уйти в детали

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

Но в System Design (и в реальной жизни) это увеличивает риски, сроки и стоимость изменений.

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

Здесь сразу комплекс ошибок:

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

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

Заблуждение № 4: UI архитектуры != системный дизайн

Есть популярная мысль: VIPER/TCA/MV{x} = системный дизайн

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

Мне очень нравится как описал проблему текущего рынка, автор книги Mobile System Design, в статье Uh oh, you picked the wrong UI architecture

UI architectures are like fashion. They go in and out of style, and they can bring fresh perspectives, but they aren’t as important as you might think

Разработчики часто гонятся за трендами, переписывают проекты под новую моду (VIPER, TCA, RIBs и т.д.), вместо того чтобы решать реальные инженерные задачи. Эти споры создают иллюзию профессионального роста, но не приближают к сути системного мышления — проектированию полезных, устойчивых и понятных систем.

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

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

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

Заблуждение № 5: Чем сложнее архитектура — тем профессиональнее

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

“The best apps at scale run on boring tech.” — Gergely Orosz

Заблуждение № 6: Mobile System Design — это просто уменьшенная копия backend-дизайна

Заблуждение, что нужно взять все принципы backend system design и применить их на клиенте.

Мобильная среда это про:

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

Поэтому mobile design == умение проектировать систему, живущую в условиях ограничений и зависимости от внешнего окружения.

“Building for mobile means designing for failure.” — Gergely Orosz

Заблуждение № 7: Главное — фреймворки и технологии

Заблуждение: “Нужно выучить Flutter, SwiftUI, KMM — тогда пойму System Design.

Фреймворки — это мода. Принципы — вечны. Систем дизайн это не про тренды современности, а про timeless principles — устойчивые принципы, которые применимы на любой платформе и не меняются из-за моды.

Заблуждение № 8: Системный дизайн — это чисто техническая дисциплина

Главное — знать паттерны и алгоритмы.

Mobile System Design — это координация людей, времени и ограничений, не только кода.

согласование между backend и дизайном,
оценка стоимости решений,
оптимизация процесса поставки продукта.

“Design is about aligning humans and systems, not only objects and classes.” — Tjeerd in ’t Veen

Как проводят собесы компании

Развенчать заблуждения — это лишь половина картины. Важно понять, как навыки Mobile System Design оцениваются в реальном мире: на собеседованиях, в задачах и в рабочих сценариях.

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

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

Шаблон проведения собесов классический:

Сбор функциональных и нефункциональных требований (5-10 минут)
Верхеуровневая схема (10-15 минут)
Детализация (20-30 минут)
Обсуждение усложнений и альтернатив

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

Yandex

Его оценка не только проектирования, но и проектного управления. Она так и называется — System Design + Project Management

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

Вам дают кейс, а дальше ваша очередь проявить инженерное мышление:

Выяснить и уточнить продуктовые требования
Спроектировать взаимодействие клиента и бэкенда — эндпоинты, ошибки, безопаность, поведение оффлайн
Разбить проект на этапы, оценить сроки и членов команды, которую будут делать разработку

HR перед собесом прямо и говорит: "Никаких идеальных схем ради красоты. Важна логика принятия решений"

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

Какие навыки проверяются?

Умение задавать вопросы и вытаскивать требования
Умение объяснять и аргументировать технические решения
Проектирование фичи как целостной системы
Учёт ограничений, нагрузки, безопасности и аудитории
Декомпозиция задач
Оценка сроков и управление ожиданиями
Распределение работ по команде
Грамотная коммуникация со смежниками

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

У них даже есть отдельный сайт с подробным описанием

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

По многим фидбэкам из комьюнити — собесы систем дизайна яндекса вызывают самые позитивные и вайбовые эмоции.

Чуть подробнее, но все же очень упрощенно, они разбирают в своем публичном мок-собесе:

Т-Банк

Секции в т-банк по фидбэкам очень спорные. Из основных минусов выделяют:

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

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

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

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

О секции с��беседований в Т-Банк — О секции собеседований в Т-Банк

Авито

Систем дизайн интервью в Авито похож на стандартный:

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

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

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

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

Остальные компании

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

тест для подготовки к SD от HR ВКонтакте

Судя по ссылкам и тексту от HR на ARC и Generics создается ощущение, что собес не на проектирование, а на лайфкодин.

Критерии и оценки на собесе

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

Я хотел провести опрос в канале, где попытался выяснить как бы оценили кандидата мои читатели:

Отсюда следует, что важны три ключевых навыка:

Архитектурное мышление и декомпозиция
Навык масштабирования системы
Навыки ясной и понятной коммуникации

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

1. Понимание задачи и требований

Что оценивается:

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

Хорошо: «Будут ли фото из чата доступны офлайн? Есть ли API для загрузки картинок или нужно проектировать?»

Плохо: Кандидат сразу переходит к паттерну, не разобрав, что нужно построить.

2. Разделение на слои

Что оценивается:

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

Пример (VIPER / MVVM / Clean Swift — не важно какой паттерн):

Хорошо: описаны интерфейсы, зависимости направлены сверху вниз, легко тестировать.

Плохо: View напрямую делает сетевой запрос

3. Слабая связанность и высокая связность

Что оценивается:

Использует ли кандидат принципы low coupling / high cohesion.
Разделяет ли ответственность (например, не смешивает работу с сетью и парсинг).

Ключевая разница между слоям и этим пунктом — видит в рамках всей системы и модулей

Хорошо: Например: NetworkService отвечает только за запросы. ParsingService — за преобразование данных. Модуль Авторизации живет с минимальными зависимостями

Плохо: Модуль Авторизации сильно зависим от модуля товаров и наоборот. Для При изменении NetworkService нужно менять еще 2-3 лишних модуля. Один класс/модуль делает всё — запрос, парсинг и отображение.

4. Использование шаблонов проектирования

Что оценивается:

Умеет ли объяснить выбор (почему этот паттерн подходит).
Насколько кандидат осознанно применяет паттерны (Observer, State, Builder, Strategy и др.).

Хорошо: "-Я использую Builder для сборки UI-компонентов, чтобы уменьшить дублирование."

Плохо: “Использую VIPER/TCA/MVI, потому что всегда так делаю.”

5. Работа с состоянием

Что оценивается:

Умеет ли проектировать состояние (state machine, single source of truth).

Исключает ли невалидные состояния (например, error != nil и data != nil одновременно).

Понимает ли потоки и асинхронность (async/await, Combine, Swift Concurrency).

Хорошо: Использует enum Loadable<T> с кейсами .idle, .loading, .loaded, .error.

Плохо: Несогласованные флаги (isLoading, hasError, isEmpty) без явной логики переходов.

6. Обоснование решений и трейд-оффы

Что оценивается:

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

Хорошо: “Выбрал MVVM вместо VIPER, потому что проект небольшой, а лишние слои только замедлят разработку.”, "На этапе реализации MVP нам не нужно создавать космолет и достаточно простого решения для проверки гипотез"

Плохо: “Так проще.”, "Я так решил", "Я нашел такое решение в ютубе, индус сказал так правильно"

7. Тестируемость

Что оценивается:

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

Хорошо: “Interactor тестируется изолированно от сети через мок.”

Плохо: “Тесты не нужны, я проверю руками.”

8. Производительность и надёжность

Что оценивается:

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

Хорошо: “При загрузке фото проверяю наличие в кеше и отменяю дублирующие запросы.”

Плохо: Все картинки грузятся одновременно без ограничений.

Понимание задачи	Задает уточнения, видит границы системы	Поверхностно понял	Не понял контекст
Слои и зависимости	Чёткое разделение, DI	Есть, но местами нарушено	Всё смешано
Паттерны	Осознанный выбор	По привычке	Не знает
Состояние и асинхронность	Ясная модель, валидные переходы	Флаги и костыли	Логика не работает
Модульность	Гибкая, расширяемая	Частично	Монолит
Тестируемость	Изолируемые компоненты	Частично	Нет
Обработка ошибок	Полная	Частичная	Игнорируется
Аргументация	Обоснованно	Формально	Без аргументов

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

Также важно как кандидат собирает требования.

Например:

Вопрос о минимальной поддерживаемой версии ОС помогает определить на какой технологии лучше всего делать. Бывали кейсы, что люди со старой ОС приносили больше денег. Такие требования лучше уточнять у интервьюера/аналитика
Нагруженность DAU/MAU приложения. Тк тут мы ожидаем вероятность появления корнер кейсов и степень проработки задач. Если баг будет у 5% от 100 человек, то это не так критично. Но уже довольно много от 1кк
Очень полезно, когда мобильный инженер проговорит не только требования к своей платформе (Android/iOS), но и к соседней. Например, бэк:
- Чем отличается REST от WebSocket'ов
- RPC, Long/Short Pooling
- JSON/Protobuf
- HTTP/HTTPS
- и другое
Дать хорошее сравнение и уметь сравнивать UI фреймворки UIkit/SwiftUi
Кроссплатформу и натив
Перфоманс и модулярицию
Базы данные и их отличия: Realm, CoreData/SwiftData, UserDefaults, Keychain, файловая система. Как хранить картины, чаты, секреты

Как Mobile System Design помогает в реальной жизни?

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

Есть несколько главных рабочих процессов для реальной жизни:

Архитектурное ревью
RFC/RnD
TDR
ADR

Все они — это как написание кода, только для архитектур, интеграций, сложных фич.

Попробуем разобрать их отдельно.

Архитектурное ревью

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

Обычно процесс такой:

Заводится задача для арх.ревью
Готовится архитектурное предложение (например, отказ от UIKit в сторону SwiftUI; Переход на Swift Councurrency)
Есть регулярная встреча архитекторов (отдельные эксперты)
Архитекторы обсуждают синхронно на встрече или комментируют асинхронно

Такой процесс самый популярный и используется во многих компаниях.

RnD & RFC

Есть также альтернатива, где архревью разделен на два этапа: R&D и RFC

Этап 1: R&D (Research & Development) — исследование технологий, прототипирование и проверка гипотез до того, как начнём полноценную разработку. Этот процесс помогает проверить работает ли идея

Этап 2: RFC (Request for Comments) — документ-предложение об изменениях в системе, архитектуре или процессах.

Цель: обсудить идею заранее, чтобы учесть риски, собрать фидбэк и согласовать реализацию.

Разберем пример из реального мира:

Видеозвонки в приложении iOS

Инженер хочет внедрить видеозвонки в приложение. Он идет по такому сценарию:

Сначала проводит RnD:

Какие технологии подходят? WebRTC, CallKit, AVFoundation?
Как повлияет на батарею и температуру устройства?
Как ведёт себя соединение при плохой сети / LTE -> Wi-Fi?
Готов ли текущий бэкенд обработать такую нагрузку?
Как CallKit влияет на UX и ограничения Apple?
Поддержка разных моделей iPhone (старые процессоры!)
Результат R&D: маленький прототип с измерением основных метрик

На этом этапе мы не строим полноценную архитектуру — мы снимаем риски.

Потом пишем RFC с таким содержанием:

Общее архитектурное решение
Взаимодействие клиент и бэк
Обработка ошибок и деградации
Безопасность данных и шифрование
Декомпозиция на этапы: MVP и улучшения

Результат RFC — согласованный план реализации

Такой процесс повышает шанс успешной реализации и упрощает постановку задачи.

Technical Design Review (TDR)

В Авито придумана альтернатива архитектурного ревью — это TDR. Это как кодревью, но для архитектурных решений. Вкратце, этот процесс ассинхроного ревью архитектурных решений с приоритетами.

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

https://www.youtube.com/watch?v=Qnw9PLSY6TM

Более подробно можно ознакомиться в их докладе

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

ADR (Architecture Decision Record) — это короткий документ, в котором фиксируется одно конкретное архитектурное решение, и почему оно было принято.

Это очень полезно тк:

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

Задачи на собеседованиях и в жизни

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

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

1. Мессенджер

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

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

Мы даже делали тренировки по систем дизайну где рисовали разные решения:

Пример проектирования чата одного архитектора из Samsung

Хороший пример детализированного чата в рамках общей систем

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

2. BDUI

Второй из популярных задач на 2025 год — это общий и любимый многими тренд на BDUI.

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

3. Аналитика

Еще одна частая и хорошая задача — проверка работы модуля аналитики.

Здесь можно проверить:

Работу с приоритетностью
Оффлайн/онлайн синхронизацию отправки
Точность и погрешность
Форматы хранения
SOLID,

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

4. Избранное

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

Как избранное будет храниться
Как обновляться между экранами
Нужно ли локальное хранение и в каких случаях
Как сихнронизовать бэк и клиент
Сущности и фильтрация

6. Инстаграм

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

Выводы:

Mobile System Design — большая и комплексная тема. Она прямой и обязательный билет на сеньорные грейды на собесах.

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