Фронтенд system design спрашивают на уровне middle+ и senior: «спроектируй ленту новостей», «чат», «автодополнение поиска», «Google Docs». Это не про бэкенд-шардирование, а про клиент: компоненты, данные, API между клиентом и сервером, производительность и устойчивость. Секция длится 45-60 минут, и оценивают не «правильный ответ», а ход мысли и умение говорить о компромиссах.
Каркас ответа (RADIO-подобный)
Держи в голове шесть этапов и проговаривай переход между ними.
1. Требования (5-10 минут). Уточни функциональные (что делает пользователь) и нефункциональные (скорость, офлайн, устройства, доступность, SEO, локализация). Спроси масштаб и что точно не входит в задачу. Запиши список, интервьюер это ценит.
2. Оценка нагрузки. На фронте это не «сколько серверов», а: сколько элементов на экране и в списке, размер ответа, частота обновлений, сколько сообщений в секунду в активном чате, как долго живёт вкладка (утечки памяти), какие устройства и сеть (3G, средний Android). Пример: лента на 1000+ постов в сессии означает виртуализацию; 50 сообщений в секунду означает батчинг обновлений.
3. API. Как клиент говорит с сервером: REST, GraphQL, WebSocket, SSE, long polling. Формат пагинации (курсорная лучше offset для живых лент: не будет дублей и пропусков при вставке новых элементов). Набросай 2-4 эндпоинта или события с полями.
GET /feed?cursor=abc&limit=20 -> { items: Post[], nextCursor: string | null }
POST /posts/:id/like -> { liked: true, likes: 124 }
WS event: { type: 'post.new', post: Post }
4. Модель данных. Какие сущности на клиенте, где лежат (серверный кеш, клиентский стор, URL, IndexedDB для офлайна), нормализованы ли. Например, posts: byId, feed: ids[], users: byId.
5. Компоненты и архитектура. Дерево компонентов верхнего уровня, кто владеет данными, как идут обновления. Стратегия рендеринга (SSR для первого экрана и SEO, клиент для интерактива).
6. Узкие места и оптимизации. Это главная часть для сеньора:
- производительность: виртуализация длинных списков, code splitting, ленивые картинки (
loading="lazy",srcset), prefetch следующей страницы; - сеть: дебаунс ввода, отмена устаревших запросов (
AbortController), кеш, дедупликация, ретраи с экспоненциальной задержкой; - надёжность: оптимистичные обновления и откат, офлайн-очередь, переподключение WebSocket;
- доступность: клавиатура, ARIA, фокус;
- безопасность: XSS в пользовательском контенте, санитизация HTML;
- наблюдаемость: Web Vitals, логирование ошибок.
Полезные числа
- Бюджет кадра при 60 Гц: около 16 мс, на свою работу остаётся примерно 10 мс.
- Ответ на действие пользователя должен ощущаться мгновенным до 100 мс, INP «хороший» до 200 мс.
- LCP «хороший» до 2,5 с, CLS до 0,1.
- Дебаунс поиска обычно 200-300 мс.
- DOM-дерево больше нескольких тысяч узлов уже заметно тормозит на слабых телефонах, отсюда виртуализация.
Типичные кейсы и ключевая идея каждого
| Кейс | Главное |
|---|---|
| Лента новостей | курсорная пагинация, бесконечный скролл через IntersectionObserver, виртуализация, оптимистичный лайк |
| Автодополнение | дебаунс, отмена старых запросов, кеш по префиксу, клавиатурная навигация, ARIA combobox |
| Чат | WebSocket, порядок и дедуп по id, статусы отправки, офлайн-очередь, подгрузка истории вверх |
| Совместный редактор | CRDT или OT, курсоры других, офлайн и слияние |
| Карусель или галерея | ленивая загрузка, предзагрузка соседних, адаптивные картинки, свайпы |
| Дашборд с графиками | частота обновлений, троттлинг, canvas вместо SVG на тысячах точек, Web Worker для расчётов |
Частые ошибки
- Сразу рисовать компоненты, не уточнив требования.
- Уходить в бэкенд (шардирование базы), когда спрашивают про клиент.
- Не называть компромиссы: «выбираю X, потому что…, минус в том, что…».
- Молчать. Секция оценивает рассуждение вслух.
Что спросят на собесе
- Спроектируй ленту, чат, автодополнение или редактор (один из кейсов).
- Какую пагинацию выберешь и почему?
- Как сделаешь список на 10 000 элементов быстрым?
- Как поведёт себя приложение без сети?
- Что будешь мерить в продакшене?