Сбор требований: функциональные и нефункциональные

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

Функциональные требования описывают, что система делает; нефункциональные — насколько хорошо она это делает (быстро, надёжно, масштабируемо).

Самая частая ошибка на собеседовании — броситься проектировать, не уточнив задачу. «Спроектируйте Twitter» — это не задача, а тема. Twitter для 1000 пользователей и для 500 миллионов — это две совершенно разные системы. Ваша первая задача — сузить формулировку вопросами.

Функциональные требования

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

Пользователь может опубликовать пост (текст, картинка).
Пользователь может подписаться на другого пользователя.
Пользователь видит ленту постов тех, на кого подписан.
Пользователь может лайкнуть и прокомментировать пост.

Сразу договоритесь, что в скоуп не входит: реклама, личные сообщения, рекомендации. Явно отрезать лишнее — признак зрелости, а не слабости. Это экономит время и фокусирует разговор.

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

Именно они определяют архитектуру. «Лента должна грузиться меньше чем за 200 мс» заставит вас добавить кэш и денормализацию. «Данные нельзя терять никогда» потребует репликации и надёжного хранилища. Ключевые группы:

Свойство	Вопрос, который оно задаёт
Доступность (availability)	Сколько простоя допустимо? 99,9% или 99,99%?
Задержка (latency)	Какая задержка приемлема? p99 < 200 мс?
Согласованность (consistency)	Нужны строго свежие данные или допустимо отставание?
Масштаб	Сколько пользователей, запросов, данных?
Надёжность (durability)	Можно ли терять данные при сбое?
Соотношение чтение/запись	Чего больше — чтений или записей? (часто 100:1)

Какие вопросы задать интервьюеру

Хороший набор уточняющих вопросов сам по себе производит сильное впечатление. Минимальный чек-лист:

- Сколько у нас активных пользователей (DAU/MAU)?
- Каково соотношение чтений и записей?
- Нужна ли свежесть данных в реальном времени?
- Какая задержка приемлема (медиана и p99)?
- Какие функции в скоупе, а какие точно нет?
- Глобальная аудитория или один регион?

Ответы превращают расплывчатую тему в измеримую задачу. Например: «5 млн DAU, чтений в 100 раз больше, чем записей, p99 < 200 мс, лента может отставать на пару секунд, один регион». Теперь у вас есть фундамент для оценок.

Пример: от темы к требованиям

Тема «сократитель ссылок» после уточнений превращается в такой контракт:

Функциональные	создать короткую ссылку из длинной; перейти по короткой → редирект; (опц.) аналитика кликов
Нефункциональные	редирект < 100 мс; доступность 99,99%; чтений ≫ записей; ссылки не должны теряться

Итог

Функциональные требования — что система делает; нефункциональные — насколько хорошо.
Архитектуру диктуют именно нефункциональные требования: latency, availability, согласованность.
Сначала сузьте задачу вопросами и явно отрежьте лишнее из скоупа.