1. System design начинается с вопросов

Обычное утро понедельника. Ничего не предвещало беды. Ты наливаешь кофе, открываешь бук, пуллишь проект и начинаешь читать ночные коммиты от коллег. Тишина, спокойствие, идиллия.

И вот он. Мерзкий, пронзающий сознание звук уведомления, от которого сводит зубы. Тебе пишет PM. Сворачиваешь проект с опаской и дурным предчувствием, открываешь диалог. А там две строчки.

“_Бизнес хочет ленту как у Threads. Какие сроки?_”

И вот тогда это происходит. Момент, когда дыхание замедляется. Ты переживаешь весь спектр эмоций. Сонм мыслей: "_Какая вам… лента? Мы же сайт для учёта бобров_", "_А Твиттер вам не написать?_". Мимо пролетают стадии от гнева до принятия.

Вдох, выдох. В такие моменты кажется, что согласиться и разбираться по ходу дела приемлемая стратегия. Но если принять такие правила игры, ошибки могут быть очень дорогими.

За красивой формулировкой про "ленту" нет конкретики. Ничего измеримого. Буквально ты не знаешь ничего.

Если сейчас не докопаться до сути, не собрать конкретные ожидания и измеримые показатели, дальше будет только хуже. Вместо простого проекта получится "челмедведосвин". Ты не сможешь его поддерживать. Вносить изменения будет сложно, развитие станет пыткой.

А что ты можешь сделать? Для начала пишешь PM: “_Мне нужно собрать требования. Организуй встречу_”.

И начинаешь подготовку к сражению. Твоим оружием будут сотни неудобных, повторяющихся и дотошных вопросов. Твоей победой станет метаморфоза влажной фантазии бизнеса в конкретные требования к проекту.

Вот почему system design начинается с вопросов, а не со схем. Вопросы это первая ступень к архитектуре. Архитектуре, которая будет работать в реальном мире, а не на бумаге.

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

Почему вопросы это не просто формальность

Вся эта история с вопросами кажется банальной. Ну спросил, ну ответили, ну записал. Что тут сложного? А сложного тут всё.

Бизнес говорит на языке результатов. "_Хотим ленту_", "_нужна аналитика_", "_сделайте как у конкурентов_", "_сделай чтоб работало_". Это нормально, они не обязаны знать, что такое eventual consistency или почему Redis не подходит для персистентного хранения.

Твоя задача перевести эти хотелки в технические требования. И вот тут начинается самое интересное.

Каждое "хочу" скрывает десятки неявных предположений. Бизнес не думает о том, что лента должна работать при 10k RPS, что данные могут быть неконсистентными первые 5 секунд, что при падении сервиса пользователи должны видеть кеш, а не белую страницу.

Они просто хотят, чтобы "_всё работало_". А что значит "_работало_" это уже твоя головная боль.

Вопросы не придирки и не попытка усложнить простую задачу. Это способ вытащить на свет все те скрытые требования, о которых бизнес даже не подозревает.

Без этого ты будешь строить систему вслепую. Сделаешь что-то, что технически работает, но не решает реальную проблему. Или решает, но с такими компромиссами, что через полгода придётся всё сжечь и написать заново.

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

Вопросы должны вытаскивать не просто пожелания, а фундаментальные ограничения системы. Архитектура это компромиссы между противоречивыми требованиями. Твоя задача найти эти противоречия до того, как они сломают систему в проде.

Начни с формальных требований, которые можно измерить и потрогать. Сколько пользователей, какие запросы, как долго система может отвечать. Это основа для всех дальнейших решений. Без цифр и строгих таргетов у тебя не проект, а путь самопознания. Если не повезёт, путь закончится не продом, а дуркой.

Но формальные требования это только верхушка айсберга. Под ними лежат неформальные требования, те, что бизнес даже не осознаёт. Что происходит, когда система падает? Пользователи ждут или уходят? Можно ли показать устаревшие данные? Что важнее, скорость или точность?

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

Не существует серебряной пули. Каждое простое решение скрывает за собой сложность. Когда бизнес просит "ленту как у Threads", он просит именно такую пулю, магическое решение, которое решит все проблемы без компромиссов. Твоя задача показать, что такой пули не существует, и помочь выбрать правильные компромиссы.

Здесь вступает в игру кибернетика. Есть закон необходимого разнообразия. Система может справиться с разнообразием внешней среды, только если у неё есть достаточное внутреннее разнообразие реакций. Проще говоря, если мир вокруг сложный, твоя система тоже должна быть сложной.

Но сложность это не хаос. Это структурированная сложность, где каждый элемент имеет роль и ограничения. Твои вопросы должны выявить не только что система должна делать, но и как она должна реагировать на изменения, сбои, пики нагрузки.

Каждое техническое противоречие можно решить, если правильно его сформулировать. Не "_нужна и скорость, и надёжность_", а "_скорость там, где важно не тормозить, надёжность там, где нельзя упасть_". Не "_нужна и простота, и функциональность_", а "_простота для тех, кто просто пользуется, функциональность для тех, кому это нужно_".

Твои вопросы должны вытаскивать эти противоречия на поверхность. Что важнее: время разработки или время отклика? Стоимость инфраструктуры или доступность? Простота поддержки или богатство функций?

Каждый ответ на твой вопрос должен приводить к архитектурному решению. Если бизнес говорит "_нужна скорость_", ты спрашиваешь "_Чем можно пожертвовать ради скорости?_". Если говорят "_нужна надёжность_", ты спрашиваешь "_Что считается сбоем?_". Если говорят "_нужна простота_", ты спрашиваешь "_Простота для кого? Для разработчиков? Для пользователей? Для бизнеса?_".

Без этих вопросов ты будешь строить систему, которая решает не ту проблему. Или решает правильную проблему, но с неправильными компромиссами. Или с правильными компромиссами, но в неправильном контексте.

Как задавать вопросы

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

Есть два типа сложности: сущностная и случайная. Сущностная это то, что нельзя убрать, не изменив саму задачу. Случайная это то, что мы добавляем сами, неправильно понимая требования. Твои вопросы должны выявить сущностную и минимизировать случайную.

Начни с широкого контекста. Собери всех заинтересованных лиц и задавай открытые вопросы. Как сейчас работает процесс? Что больше всего бесит в текущем решении? Что будет, если ничего не менять? Цель понять общую картину, не вдаваясь в детали.

Записывай всё. Даже то, что кажется неважным. Потом разберёшься. Часто самые важные ограничения скрываются в мелочах, которые кажутся очевидными.

Теперь иди к каждому стейкхолдеру отдельно. У них разные интересы и приоритеты. Продукт думает про пользовательский опыт, бизнес про деньги, эксплуатация про стабильность. Каждый видит систему под своим углом, и твоя задача собрать эти углы в единую картину.

Не принимай ответы типа "_ну, как обычно_" или "_сделайте нормально_". Докапывайся до цифр. Если говорят "_быстро_", спрашивай "_Что для вас значит быстро? Сколько миллисекунд, секунд?_". Если говорят "_надёжно_", спрашивай "_Что считать сбоем? Сколько девяток доступности? Что видит пользователь при сбое?_".

К этому моменту у тебя будет список требований длиной в километр. Большинство из них будут противоречить друг другу. Это нормально. Система живёт в мире ограниченных ресурсов, где нельзя получить всё сразу.

Время для взрослых разговоров. Что важнее: скорость или надёжность? Простота или функциональность? Бюджет или качество? Не пытайся угодить всем. Лучше честно сказать "_это требование увеличит сроки в два раза_" и дать бизнесу принять решение.

Оформи всё в документ. Не в виде списка пожеланий, а в виде конкретных, измеримых требований. "_Система должна поддерживать тысячу одновременных пользователей_" вместо "_должна быть надёжной_". "_Время ответа API не должно превышать 200 миллисекунд в 95 процентах случаев_" вместо "_должна работать быстро_".

Этот документ станет основой для всех дальнейших решений. Каждое архитектурное решение должно быть обосновано конкретным требованием из этого документа. Если не можешь объяснить, зачем нужен тот или иной компонент, значит, этот компонент лишний.

Посмотрим как это работает на примере.

Cценарий 1: Сам решил

PM приходит с задачей. "_Бизнес хочет ленту новостей. Сделайте как у Threads_".

Ты спрашиваешь: "_А что именно имеется в виду?_"

PM отвечает: _"Ну, лента. Где посты идут в хронологическом порядке, с лайками и комментариями"_.

Вроде понятно. Ты киваешь, но в голове уже крутится: "_А что, если пользователей будет много? А если нагрузка вырастет? А если понадобится поиск?_".

Хоронишь эти вопросы в себе и накидываешь схему. Таблицы posts, likes, comments. API для получения ленты. И вроде красиво. Микросервисы. Кафка, прости господи, чтобы общались. Valkey за кэш. Поиск на эластике. Ну и докер, кубер, графана, прометеус. Всё как у взрослых.

Через месяц выкатываешь на прод. Сотня пользователей заходит одновременно, и система падает.

Бизнес задаёт неудобные вопросы: "Почему ничего не работает? Почему так медленно? У Threads же быстро работает!"

Ты начинаешь оптимизировать. Добавляешь кеши, тюнишь Kafka, добавляешь реплики. Каждая правка ломает что-то ещё. Через полгода у тебя зоопарк микросервисов, devops-шапито и система, которую никто не понимает, и все боятся трогать. Поздравляю, ты создал legacy.

Cценарий 2: Наорал

Ты не киваешь. Ты хватаешь PM, привязываешь его к стулу и начинается, хм, диалог.

Ты задаёшь вопросы. Сначала PM. Кто пользователи? Сколько постов в день? Кто пишет? Что пишут? Как часто заходят? А сколько пользователей через пол года, год? Что важнее, скорость или актуальность? Что считается сбоем? Можно ли показывать устаревшие данные?  А нужна аналитика? А архивировать будем? Поиск нужен? Реагируем на лайки сразу? Комментарии сразу видно? А подписки? А уведомления? И так далее.

Потом идешь вместе с PM пытать бизнес и эксплуатацию.

Через несколько дней у тебя полная картина. 5к активных пользователей. Сто постов в день. Пик нагрузки в обед и вечером. Главное — скорость. Можно жертвовать актуальностью лайков и комментариев. Простои до получаса допустимы. Архивируем через пол года. Поиск простой. Рост медленный. И тд. и тп.

Ты делаешь схему под это. Одна таблица posts с денормализованными данными. Один Valkey для кеша с TTL пять минут. Никакой плеяды микросервисов. Никаких очередей. Одна база, один сервис.

Лента открывается быстро. Система держит нагрузку. Код простой, понятный, надёжный. Бизнес доволен. Тебе не задают неудобные вопросы.

Всё то модное, что ты впихнул в первом сценарии, оказалось ненужным.

Во втором случае ты потратил часы на вопросы, но сэкономил месяцы на разработке и поддержке. Вопросы помогли увидеть реальную задачу и отбросить лишнее.

Что в итоге

System design это не про схемы. Это умение задавать правильные вопросы и вытаскивать из бизнеса реальные требования, а не слепо следовать его влажным фантазиям.

Без вопросов ты строишь систему вслепую. С вопросами решаешь конкретную задачу конкретными средствами.

Но вопросы это только начало. Дальше нужно понять, как переводить требования в архитектурные решения, выбирать правильные компромиссы и не поддаваться на соблазн "_сделать как у больших дядек_".

В следующих частях расскажу, почему system design держится на трех принципах, как из требований получается архитектура, как выбирать правильные компромиссы и почему простое решение часто лучше сложного.

А пока перестань кивать на хотелки бизнеса и начни задавать неудобные вопросы. Скажешь себе потом спасибо.

Что еще почитать?