Привет, Хабр!
Я — Зинченко Иван, IT-Lead в направлении разработки цифровых каналов в Газпромбанке. За последние 3 года я провёл и прошел десятки собеседований по System Design и заметил: 80% кандидатов проваливаются на одной и той же ошибке - не фиксируют основные требования к системе.
В этой статье разберем чем чреват этот критичный промах, который даже сильные разработчики допускают при проектировании систем.
Для чего нам нужны требования?
Сбор и фиксация требований это первый и самый важный этап при Проектировании IT-Системы. Данный этап нельзя проходить стороной, так как от того, насколько правильно вы зафиксируете требования будет зависеть результат решения задачи или собеседования. Давайте же разберемся почему это так важно, зачем нужны требования и почему же им следует уделять столько внимания.
Требования — это основа (фундамент) Проектирования любой системы. Они определяют что, как и в каких условиях должна делать система.
Без четких требований проектирование превращается в хаотичный процесс, который может привести к:
Неработоспособной архитектуре (IT-Система не справляется с нагрузкой или не отвечает требованиям заказчика).
Перерасходу ресурсов (ненужная сложность, дорогие технологии без причины).
Провалу бизнес-целей (система не решает нужные задачи).
Пример:
Стартап разработал монолит, но через год потребовалось масштабирование.
Пришлось экстренно дробить систему на микросервисы — 2 месяца работ.
Требования определяют:
Что нужно построить (функции);
Как система должна работать (производительность, надежность и тд.);
Ограничения (бюджет, сроки, технологии).
Что нам дают требования?
Когда мы понимаем, что на самом деле определяют требования, давайте обсудим что они при всем при этом дают. А дают они: Четкое понимание цели.
Требования отвечают на вопросы:
1. Что система должна делать? (функции).
2. Для кого? (пользователи, администраторы).
3. В каких условиях? (нагрузка, безопасность, бюджет).
Пример:
Система должна обрабатывать 1000 платежей в секунду с задержкой <200 мс» — это конкретное требование, которое сразу задает вектор проектирования.
Требования помогают проверить, что система работает правильно:
Например если мы говорим о функциях системы интернет-магазина - «Пользователь может создать заказ». Это можно проверить, проведя тестирование и анализ построенной системы.
Если мы говорим об условиях в которых работает наша система - «Заказ создается за <1 сек при 10K RPS». Проведя специальные тесты мы также можем проверить, что наша система соответствует требованиям.
Требования дают основу для архитектурных решений:
1. Выбор между той или иной технологией или приеме.
2. Выбор паттернов (шаблонов).
Требования связывают бизнес-цели и техническую реализацию. Они защищают от ошибок на ранних этапах, а это важно. Без требований System Design — гадание на кофейной гуще и если пропустить этот этап — придется переделывать архитектуру.
Если на собеседовании по System Design не уделить внимание требованиям, это почти гарантированно приведёт к провалу — даже если ваше техническое решение идеально.
Пример:
Интервьюер спрашивает: «Спроектируйте сервис сокращения ссылок».
Вы сразу рисуете:
Шардированную БД,
Глобальный CDN,
Резервные дата-центры.
Проблема:
А если сервис нужен только для внутреннего использования с нагрузкой 100 RPS? Ваше решение избыточно и дорого.Что спросит интервьюер:
«Зачем вам 6 серверов, если хватит одного?» → Вы теряете баллы за неадекватную оценку.
Простыми словами, не спешите сразу бросаться с бой и рисовать красивые схемы. System Design это про уникальность, а не шаблонность. Из зоопарка паттернов и технологий, необходимо выбрать именно тот набор, которые подходит под решение конкретной задачи. Так что зазубрить 1 архитектуру на все случаи жизни не получится. Без уточнения требований, ваш System Design будет напоминать хождение в темном лесу, ночью с закрытыми глазами в надежде выйти из чащи.
Алгоритм уточнения требований
Пусть мы с вами оказались на собеседовании. Интервьюер (тот кто проводит собеседование), просит вас спроектировать Маркетплейс (интернет-магазин).
При уточнении требований на собеседовании по System Design важно задавать конкретные и структурированные вопросы, чтобы раскрыть неочевидные аспекты задачи. Ниже представлен чек-лист.
1. Уточнение функциональных требований
Ключевые вопросы:
1. Какие основные функции должна поддерживать система?
Пример: «Нужен ли полнотекстовый поиск товаров или только фильтрация по категориям?»
2. Какие сценарии использования являются приоритетными?
Пример: «Система чаще используется для чтения (просмотр товаров) или записи (оформление заказов)?»
3. Какие ограничения по данным?
Пример: «Максимальный размер файлов для загрузки?»
2. Нефункциональные требования
Критичные аспекты:
1. Масштабируемость:
Пример: «Ожидаемое количество пользователей в пик? Рост через год?»
2. Надежность и доступность:
Пример: «Какие компоненты должны быть отказоустойчивыми? Допустимо ли временное несоответствие данных (eventual consistency)?»
3. Производительность:
Пример: «Какое время отклика приемлемо для API поиска? Нужна ли поддержка реального времени?»
4. Отзывчивость:
Пример: «Насколько быстро становятся активными все элементы, с которыми может взаимодействовать пользователь.»
3. Данные и их характеристики
Уточните:
1. Объем данных:
Пример: «Сколько новых заказов в день? Какой средний размер товара в БД?»
2. Шаблоны доступа:
Пример: «Часто ли обновляются данные товаров? Есть ли «горячие» записи?»
3. Хранение:
Пример: «Нужен ли архив старых заказов? Как долго хранить логи?»
4. Интеграции и экосистема
Важные вопросы:
1. Внешние сервисы:
Пример: «Интеграция с платежной системой или CRM? Какие у них API-лимиты?»
2. Безопасность:
Пример: «Требуется ли шифрование установка ограничителя доступа? Нужна ли аутентификация для всех endpoint-ов?»
5. Ограничения и допущения
Уточните явно:
1. Бюджет/инфраструктура:
Пример: «Можно ли использовать облачные сервисы (AWS/GCP), или только собственное железо?»
2. Технологический стек:
Пример: «Есть ли ограничения на БД (только реляционные или можно NoSQL)?»
3. Границы задачи:
Пример: «Нужно ли проектировать только backend, или проектируем включая CDN и кэширование?»
6. Проверка гипотез
Примеры уточнений:
«Правильно ли я понимаю, что система должна обрабатывать 10K RPS для API поиска?»
«Допустимо ли использовать Redis как основное хранилище корзин, или это должно быть PostgreSQL?»
7. Планы на будущее
Примеры уточнений:
«Планируется ли увеличение количества пользователей через 1 год, 3 года, 5 лет?»
«Какие новые функции могут резко заинтересовать пользователей в будущем?»
Короткий Чек-лист для собеседования
Функции: Какие операции MUST HAVE vs NICE TO HAVE?
Масштаб: Пиковые нагрузки, рост данных, геораспределение.
Надежность: SLA, допустимые простои, требования к бэкапам.
Данные: Объем, частота обновления, шаблоны чтения/записи.
Интеграции: Зависимости от внешних сервисов.
Ограничения: Бюджет, сроки, стек.
Планы на будущее: Изменение пользовательского трафика со временем.
Советы
1. Говорите вслух: Озвучивайте свои предположения.
Пример: «Я предполагаю, что поиск товаров — это 80% нагрузки, поэтому предлагаю выделить отдельный индекс в Elasticsearch».
2. Пользуйтесь методом 5W: Who (Кто пользователи?), What (Какие данные?), Where (Геораспределение?), When (Пиковые часы?), Why (Цель системы?).
Пример диалога на собеседовании
Кандидат:
«Вы упомянули, что система должна отображать актуальный остаток товаров. Это означает, что нам нужна строгая согласованность (strong consistency) для обновлений инвентаря? Или допустимо небольшое окно неконсистентности в 1-2 секунды?»
Интервьюер:
«Допустимо eventual consistency (конечная согласованность) с задержкой до 5 секунд».
Кандидат:
«Тогда предлагаю использовать Cassandra для инвентаря с кэшированием в Redis, чтобы балансировать между скоростью и согласованностью».
Бонус
Если вы желаете познать все тонкости System Design, не только формирование требований, но и хотите научиться проектировать надежные и масштабируемые системы как Google, Netflix, Яндекс, Amazon или вы готовитесь к собеседованию по System Design - смело записывайтесь на мой курс на Степике: C нуля до проектирования систем уровня senior-инженера.. Специально для Хабра действует промокод 20% HABR20
Спасибо за внимание и удачи!
