Основы System Design

Сначала понять задачу, потом рисовать архитектуру

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

В этом разделе мы соберём базовый набор понятий, который понадобится почти в любой задаче на проектирование системы. Здесь не будет готовой «идеальной архитектуры» — вместо неё появится последовательный способ рассуждать о системе.

Что разберём

• Процесс проектирования. Научимся двигаться от постановки задачи к общей схеме системы и проверять решение на слабые места.
• Функциональные требования. Разберём, как зафиксировать действия и сценарии, которые система обязана поддерживать.
• Нефункциональные требования. Посмотрим на скорость, масштабирование, доступность и другие свойства, которые определяют качество системы.
• Latency и Throughput. Разделим два разных вопроса: насколько быстро выполняется отдельный запрос и сколько работы система способна обработать за единицу времени.
• Доступность и надёжность. Поймём, чем «сервис сейчас отвечает» отличается от «система работает правильно и предсказуемо».
• Stateless и Stateful. Разберём, где живёт состояние системы и почему это напрямую влияет на масштабирование и отказоустойчивость.
• Архитектурные компромиссы. Научимся смотреть на решение не как на набор плюсов, а как на обмен одних свойств системы на другие.

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