Системный дизайн (System Design)

Зачем для UCP. Прежде чем писать спеку и код сервиса, систему надо спроектировать: числа, хранилища, стрелки, отказы. Этот раздел — практический метод дизайна; его выходы (схема, развилки, поведение) дальше живут в ADR и UCP-спеках. Входит в программу подготовки.

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

Статьи раздела

1. Три качества системы — надёжность, масштабируемость, сопровождаемость: вокруг чего вообще крутится дизайн и почему среднее время ответа врёт.
2. Метод: шаг за шагом — девять шагов от требований к архитектуре и четыре принципа, которые держат процесс.
3. Строительные блоки и их цена — кеш, репликация, шардинг, очереди, поиск, аналитика: что покупает, чем платится, по какому числу появляется.
4. Сквозной пример: система уведомлений — весь метод на одной задаче, от салфетки до таблицы отказов.
5. Оформление и защита: design doc, C4, ревью — как дизайн становится решением.

Теория, на которую опирается метод

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

• Фундамент данных — движки хранения, OLTP и OLAP, репликация, шардинг, производные данные, потоки.
• Распределённые системы — частичные отказы, ненадёжные часы, линеаризуемость, консенсус, корректность.

Связанное

• Архитектурный выбор — развилки шагов 5–6: хранилища, sync/async, веб-стек.
• Модель C4 — язык диаграмм для схемы.
• Распределённые паттерны — outbox, saga, идемпотентность в связках блоков.
• Use Case Pattern — куда уезжает поведение после ревью дизайна.