Процесс проектирования

Проектирование — это последовательность вопросов

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

Хороший процесс идёт от общего к частному. Сначала уточняем цель системы, затем фиксируем требования и только потом выбираем компоненты, которые помогают эти требования выполнить.

Problem
  ↓
Requirements
  ↓
Constraints and scale
  ↓
High-level design
  ↓
Critical components
  ↓
Check bottlenecks and trade-offs

1. Уточнить границы задачи

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

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

2. Зафиксировать требования и ограничения

Дальше разделяем то, что система делает, и то, как хорошо она должна это делать. В следующих темах мы отдельно разберём функциональные и нефункциональные требования. Здесь важно лишь понимать: именно они становятся критериями, по которым потом оценивается архитектура.

3. Нарисовать минимальную рабочую схему

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

Client → API → Application → Storage

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

4. Углубиться в критичные места

Не все части системы одинаково важны. Где-то главным риском станет хранение данных, где-то — большое число чтений, а где-то — длительная обработка запросов. Поэтому после общей схемы полезно выбрать несколько наиболее важных мест и проработать именно их.

5. Проверить решение на рост и отказ

Последний проход — мысленно «сломать» собственную архитектуру. Что произойдёт, если запросов станет больше? Если один компонент перестанет отвечать? Если данные начнут расти быстрее ожидаемого? Такие вопросы обнаруживают слабые места раньше, чем система попадёт в продакшен.