Backend, frontend, mobile, data и ML-системы требуют одной и той же инженерной зрелости, но стартуют из очень разных ограничений и типичных источников проблем.
Глава показывает, как один и тот же архитектурный разговор меняется между доменами: где-то решают задержка и масштабирование, где-то жизненный цикл клиента и интерфейс, а где-то путь данных, качество признаков или выпуск модели.
Для подготовки это особенно полезно, потому что помогает не натягивать один шаблон на все роли, а заранее понимать, какой трек вас ждёт и где именно нужно усиливать профиль.
Практическая польза главы
Доменные ограничения
Сравнивайте, какие ограничения определяют ответ в каждом треке: сеть, интерфейс, данные, модель или инфраструктура.
Нефункциональные требования
Заранее решайте, какие доминируют именно в вашем домене, а какие остаются вторичными.
Границы ответственности
Уточняйте, кто владеет интерфейсом, данными, клиентом и инфраструктурой, чтобы решение было выполнимым для реальной команды.
Адаптация подхода
Показывайте, как один и тот же архитектурный каркас меняется между треками без шаблонных и одинаково звучащих ответов.
для серверного инженера, фронтенд-разработчика, мобильного специалиста, data-инженера и ML-команды похоже только внешне. Во всех случаях ждут зрелого архитектурного мышления, но исходные ограничения, типичные сбои и признаки сильного ответа заметно меняются вместе с доменом.
Один формат, разные доменные акценты
Системный дизайн меняется вместе с ролью: серверный, клиентский, мобильный, data- и ML-треки проверяют разные ограничения.
Сервер
Масштабирование, надёжность, хранилища, очереди и внешние API.
держит нагрузку
Клиент
Рендеринг, состояние интерфейса, доступность и пользовательский путь.
видит браузерные границы
Мобильный клиент
Сеть, батарея, память, локальные данные и синхронизация.
учитывает устройство
Данные и ML
Конвейеры, качество данных, признаки, вывод модели и мониторинг.
понимает жизненный цикл
Практический вывод
Перед подготовкой важно уточнить доменный трек: один и тот же каркас ответа должен менять глубину и словарь под роль.
Распространённость доменных треков
Это ориентировочная картина рынка, а не строгая статистика. Она помогает понять, какие треки встречаются чаще и какие доменные ожидания полезно разобрать заранее.
Фундамент
Веб-протокол
Базовый протокол, на котором строится значительная часть внешних API и серверных интеграций.
Серверные системы
Классический серверный трек
Серверный разбор остаётся базовой формой архитектурного интервью. Здесь ждут уверенного разговора о распределённых сервисах, масштабировании, надёжности и о том, как система ведёт себя под реальной нагрузкой.
Ключевые компоненты
- Балансировщики нагрузки
- SQL- и NoSQL-базы
- Кэши вроде Redis и Memcached
- Очереди и стримы, например Kafka и SQS
- Сети доставки контента и шлюзы API
Типичные задачи
Фокус оценки
Масштабирование, доступность и цена разных режимов согласованности.
Нефункциональные требования
Задержка, пропускная способность и устойчивость к отказам.
Углубление
Шардирование, репликация, кэширование и .
Фронтенд и клиентский веб
Архитектура веб-клиента
Во фронтенд-треке в центр разговора выходят границы клиентской архитектуры, производительность рендера, управление состоянием и . Если приложение рендерится на сервере, почти всегда обсуждают и : как браузер подхватывает уже готовую страницу и где на этом пути теряется отзывчивость.
Фреймворк RADIO
Ключевые темы
- Компонентная архитектура и модульность
- Управление состоянием: Redux, контекст React, Zustand
- , CSR и статическая генерация с гидратацией
- Производительность: , FID, CLS
- и отложенная загрузка
Типичные задачи
Оптимизации
Виртуализация списков, постепенная загрузка изображений, debouncing и работа с размером bundle.
Отличия от серверного трека
Меньше разговора про инфраструктуру и базы, больше — про поведение интерфейса, браузерную среду и пользовательский путь.
Фундамент
Android: мобильная ОС
Архитектура и ограничения мобильной ОС, которые определяют устройство клиентского приложения.
Mobile и приложения на устройстве
Архитектура iOS- и Android-приложения
В mobile-дизайне быстро выходят на первый план приложения, нестабильная сеть, память, батарея и . Хороший ответ здесь показывает, как приложение остаётся полезным без идеальной связи и как безопасно синхронизирует локальное состояние с сервером.
Локальная работа без сети
Локальная база становится главным источником состояния, а синхронизация идёт фоном через слой репозитория и медиатор удалённых данных.
Батарея и память
Экономное использование фоновых задач, изображений, памяти и сети под ограничениями устройства.
Стратегии синхронизации
Push-уведомления, , и разрешение конфликтов между локальными и серверными изменениями.
Архитектурные паттерны
Типичные задачи
Что делает mobile-трек особенным
Data и платформы данных
Платформа и конвейеры данных
Data-разговор крутится вокруг пути данных: от источников и преобразований до аналитических витрин и нижестоящих потребителей. Здесь естественно обсуждать , и , а также то, как система балансирует задержку, качество и стоимость обработки.
Путь данных — 5 слоёв
Источники
Обработка
Хранение
ML/AI
Потребители
Ключевые концепции
Spark и Airflow против Kafka и Flink — разница в задержке и способе доставки данных.
Когда схему фиксируют до загрузки, а когда — уже внутри аналитической платформы.
Инкрементальная доставка изменений из в аналитику и нижестоящие сервисы.
Medallion Architecture
Сырые, неизменяемые данные
Очищенные и провалидированные наборы
Бизнес-витрины и агрегаты для BI
Технологический стек
Типичные задачи
ML и системы с моделями
и вывод моделей
ML-трек добавляет к классическому серверному разговору , контур , моделей и мониторинг . Здесь важно показать не только архитектуру сервиса, но и дисциплину вокруг качества данных и выпуска моделей.
Сильный ответ почти всегда затрагивает , признаков и моделей, а также , без которой невозможно надёжно разбирать ошибки и регрессии.
Архитектура ML-конвейера
Приём данных
Хранилище признаков
Обучение
Реестр моделей
Вывод
Хранилище признаков
Централизованное место для признаков, которые используются и в обучении, и в рабочем контуре. Оно помогает удерживать одинаковую логику расчёта между экспериментами и продакшеном.
Для batch-обучения
Для вывода в реальном времени
Вывод модели
Стратегии выката
- Канареечный релиз
- A/B-тестирование
- Теневой деплой
- Blue-Green
Мониторинг
- Обнаружение дрейфа данных
- Качество модели: P/R/AUC
- Задержка и пропускная способность
- Распределение признаков
Типичные задачи
Ключевой вопрос в ML-треке
«Как вы обеспечите согласованность между признаками, которые используются в обучении, и признаками, которые попадают в продакшен-контур?» Хороший ответ почти всегда упирается в хранилище признаков, общий расчёт признаков, версионирование и понятную историю происхождения данных.
Сравнение доменных треков
| Аспект | Backend | Frontend | Mobile | Data | ML |
|---|---|---|---|---|---|
| Главный фокус | Масштабирование сервиса | UX и рендеринг | Работа без сети и ресурсы устройства | Движение и качество данных | Жизненный цикл модели |
| Приоритет нефункциональных требований | Задержка, пропускная способность | LCP, FID, CLS | Батарея, память | Свежесть, точность | Точность, задержка |
| Главное состояние | БД и кэш | Клиентское состояние | Локальная БД и синхронизация | Озеро и хранилище данных | Хранилище признаков |
| Рабочая рамка | 4-шаговый подход Алекса Ксю | RADIO | MVVM + репозиторий | 5-слойный путь данных | ML-конвейер |
| Типичная длительность | 45-60 мин | 45 мин | 45 мин | 45-60 мин | 45-60 мин |
Ключевые выводы
Серверный трек остаётся базовым ориентиром, но уже не покрывает весь спектр архитектурных интервью.
Фронтенд смещает акцент в сторону интерфейса, рендера, состояния и пользовательского пути.
Mobile проверяет, умеете ли вы проектировать под плохую сеть, батарею, память и автономную работу клиента.
Data концентрируется на движении данных, слоях обработки и балансе между качеством, задержкой и стоимостью.
ML добавляет к архитектуре системы модели, признаки, выпуск и мониторинг качества после релиза.
Уточняйте доменный трек — заранее спросите у рекрутера, какой тип архитектурного интервью ожидается для вашей роли.
Связанные главы
- Как устроен раздел про подходы к проектированию систем - даёт карту всего раздела и помогает понять, зачем вообще различать доменные треки на архитектурном интервью.
- Фреймворки интервью по системному дизайну - показывает базовый каркас разговора, который потом приходится адаптировать под серверный, клиентский, мобильный, data- и ML-трек.
- Интервью по системному дизайну: 7-шаговый подход - объясняет, как один и тот же interview framework меняет глубину и приоритеты в зависимости от домена.
- Зачем нужна архитектура фронтенда и как она влияет на System Design - углубляет фронтенд-трек: клиентская архитектура, производительность рендера, состояние интерфейса и границы браузера.
- Android: мобильная ОС - добавляет платформенный контекст для mobile-трека: ограничения ОС, жизненный цикл приложения и работа устройства под нагрузкой.
- Фреймворк выбора СУБД - помогает осмысленно выбирать хранилища под форму доступа, нагрузку и требования к данным в серверных и data-кейсах.
- Machine Learning System Design Interview (short summary) - переносит общий архитектурный подход в ML-домен: признаки, вывод модели, эксплуатация и качество данных.
- Observability & Monitoring Design - дополняет любой доменный трек практикой метрик, логов, трассировок и оповещений.