Перейти к основному содержимому

Frontend System Design

Для чего модуль​

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

Результат после прохождения​

  1. Вы декомпозируете frontend-систему на подсистемы, контракты и потоки данных.
  2. Вы проектируете решение с учетом NFR: производительность, надежность, безопасность, observability.
  3. Вы умеете вести дизайн-сессию: требования -> архитектура -> риски -> rollout.
  4. Вы защищаете решение под challenge-вопросами интервьюера/архитектора.

Термины и аббревиатуры​

ТерминКоротко
NFRНефункциональные требования
SLOЦелевой сервисный уровень
Latency budgetЛимит задержки
RolloutПоэтапный выпуск
MitigationСнижение риска

Фокус по грейдам​

  1. Junior: понимать базовые механики и объяснять их простыми примерами.
  2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
  3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем​

  1. На каждый урок берите один system design кейс (feed, dashboard, chat, admin platform).
  2. Всегда фиксируйте assumptions и open questions.
  3. Каждое решение связывайте с метрикой и operational cost.

Программа модуля​

Урок 1. Фреймворк системного ответа​

Цель: выстроить стабильный шаблон ответа на system design задачу.

Последовательность ответа​

  1. Clarify requirements.
  2. Определить масштабы и ограничения.
  3. Предложить high-level архитектуру.
  4. Углубиться в 1-2 критичные подсистемы.
  5. Риски, компромиссы, rollout plan.

Что ценится на интервью​

  1. Структура мышления.
  2. Осознанные trade-offs.
  3. Умение признавать неопределенность и работать с ней.

Мини-задача (обязательная)​

Сделайте 15-минутный design pitch для кейса «новостная лента с персонализацией».

Что спросит интервьюер: как вы определяете границы системы до выбора технологий.

Критерий готовности по уроку: вы можете дать связный high-level дизайн за ограниченное время без потери логики.

Урок 2. Нефункциональные требования​

Цель: проектировать систему с учетом ограничений, а не только happy-path функционала.

NFR, которые чаще всего решают исход​

  1. Performance (LCP/INP, latency budgets).
  2. Reliability (error budget, fallback).
  3. Security/privacy.
  4. Scalability и team maintainability.

Работа с нагрузкой и деградацией​

  1. Caching strategy на уровне данных/маршрутов.
  2. Rate limits и graceful degradation.
  3. Приоритеты: какие функции должны работать при частичном отказе.

Мини-задача (обязательная)​

Для выбранного кейса сформулируйте NFR + SLO + budgets и покажите, как они влияют на архитектурный выбор.

Что спросит интервьюер: какие нефункциональные требования для этой системы критичны и почему.

Критерий готовности по уроку: вы связываете архитектуру с NFR и можете объяснить цену каждого компромисса.

Урок 3. Эволюция системы​

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

Growth planning​

  1. Что произойдет при росте x10 пользователей.
  2. Где bottleneck по данным, рендеру, интеграциям.
  3. Какие части нужно выделить/перепроектировать первыми.

Migration/rollout​

  1. Этапность изменений.
  2. Backward compatibility.
  3. Rollback plan на каждом шаге.

Мини-задача (обязательная)​

Сделайте evolution roadmap на 6-12 месяцев для вашего system design кейса: этапы, риски, метрики выхода.

Что спросит интервьюер: как будет эволюционировать решение при росте трафика и команды.

Критерий готовности по уроку: вы можете показать реалистичный план роста системы без «перепишем потом».

Урок 4. Защита решения на интервью​

Цель: выдерживать challenge-вопросы и защищать решение аргументированно.

Типичные challenge-вопросы​

  1. Почему не более простое решение?
  2. Где single point of failure?
  3. Что будет при отказе ключевой зависимости?
  4. Как это поддерживать командой из N человек?

Шаблон ответа на challenge​

  1. Подтвердить риск/ограничение.
  2. Показать, как текущий дизайн его покрывает.
  3. Если не покрывает — предложить phased improvement.

Мини-задача (обязательная)​

Проведите mock-defense: 5 жестких вопросов по вашему дизайну + письменные ответы по шаблону.

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

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

Практика​

1. Design doc for one critical product flow​

Связка: Senior q-1, Senior q-5..q-7, Senior q-10.

Что сделать:

  1. Выберите один кейс: checkout, search, dashboard, profile settings или admin table.
  2. Заполните design doc: goal, users, constraints, NFR, data ownership, state ownership, API boundary, error states, observability.
  3. Для critical path опишите failure modes: stale data, retry storm, optimistic rollback, partial/unavailable state, missing correlation id.

Артефакт: one complete design doc + failure-mode table.

Критерий готовности: вы ведете системный дизайн от пользовательского сценария к boundaries, reliability и observability, а не рисуете абстрактные boxes.

2. NFR, capacity и bottleneck plan​

Связка: Senior q-3, Senior q-13, Senior q-14..q-15.

Что сделать:

  1. Для выбранного кейса задайте NFR: LCP/INP/CLS, availability, error-free journey, p95 interaction, data freshness.
  2. Сделайте x10 growth map: traffic/data/team growth -> bottleneck -> mitigation -> validation signal.
  3. Добавьте decision matrix для большого списка, тяжелого вычисления, network payload или rendering mode.

Артефакт: NFR/SLO table + x10 bottleneck map.

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

3. Rollout, rollback и API compatibility​

Связка: Senior q-12, Senior q-18, Senior q-19.

Что сделать:

  1. Составьте rollout/rollback plan: change -> flag/cohort -> gates -> signals -> stop condition -> rollback action -> owner -> comms.
  2. Добавьте API compatibility checklist для одного breaking-risk изменения: field add, rename, enum expansion или pagination default change.
  3. Опишите postmortem trigger: когда нужен postmortem даже при быстром rollback.

Артефакт: rollout/rollback plan + API compatibility checklist.

Критерий готовности: вы показываете, как design safely ships, evolves и откатывается без поломки consumers.

4. Mock-defense под давлением​

Связка: Senior q-20, Playbook, Interview pattern taxonomy.

Что сделать:

  1. Проведите 45-minute dry run: 30 минут design, 15 минут Q&A.
  2. Подготовьте ответы на 5 challenge-вопросов: simpler solution, SPOF, dependency outage, team ownership, cost/performance trade-off.
  3. Для каждого ответа используйте шаблон risk acknowledged -> current coverage -> remaining gap -> phased improvement.

Артефакт: timed design rehearsal notes + challenge answer sheet.

Критерий готовности: вы защищаете дизайн структурно, признаете ограничения и предлагаете phased improvement вместо ухода в спор.

Связь с треками и вопросами​

  1. System boundaries and state/data ownership: Senior q-1, Senior q-5..q-7, Senior q-10.
  2. Performance/reliability NFR: Senior q-3, Senior q-13, Senior q-14..q-15.
  3. Evolution and delivery: Senior q-12, Senior q-18..q-20.
  4. Interview polish: Playbook and Interview pattern taxonomy.

Критерий готовности​

Ready: вы ведете системный диалог от requirements and NFR до boundaries, rollout, observability, failure modes and evolution roadmap.

Partial: у вас есть boxes and flows, но нет NFR, stop condition, owner, compatibility plan or challenge answers.

Not ready: вы пересказываете дизайн без рисков, альтернатив, rollout/rollback и проверяемых сигналов.

Артефакты после модуля​

  1. Complete design doc for one critical product flow.
  2. Failure-mode table.
  3. NFR/SLO table + x10 bottleneck map.
  4. Rollout/rollback plan.
  5. API compatibility checklist.
  6. Timed design rehearsal notes + challenge answer sheet.

Куда дальше​

  1. Tooling и Delivery
  2. Node.js
  3. Frontend System Design