System design и архитектура приложений: паттерны, чистая архитектура и масштабирование для мидла
System design — навык проектировать приложение целиком: уточнить требования, посчитать нагрузку и объём данных, разложить систему на компоненты и решить, где нужны кеш, реплика базы, очередь или шард и что произойдёт при отказе одного узла. Архитектура приложения решает ту же задачу на уровне кода: как разделить сервис на слои, чтобы бизнес-правила не зависели от базы и фреймворка. Мидлу оба умения нужны, чтобы брать задачи шире одного эндпоинта и пройти секцию system design на собеседовании. Дальше — учебный расчёт, приёмы масштабирования, согласованность, порядок освоения и выбор обучения.
Содержание
Частое заблуждение — считать system design набором готовых схем: балансировщик, Redis, Kafka, три реплики. Схема без цифр ничего не доказывает. Кеш оправдан, когда чтений намного больше, чем записей, а шардирование — когда одна база не вмещает данные или не успевает их записывать. Поэтому навык начинается с вопросов к заказчику и арифметики, а технологии выбирают последними.
Два уровня: система и код
System design смотрит на систему снаружи: из каких процессов и хранилищ она состоит, как между ними ходят запросы, сколько экземпляров каждого компонента понадобится. Архитектура приложения смотрит внутрь одного сервиса: какие в нём слои и куда направлены зависимости. Ошибка первого уровня проявляется под нагрузкой, второго — когда любая доработка задевает десяток файлов. Связать уровни помогает модель C4 Саймона Брауна: диаграммы контекста, контейнеров, компонентов и кода. Роль архитектора ПО, отвечающего за такие решения в масштабе компании, разобрана в соседней статье о профессии; здесь речь о навыке разработчика.
Учебный пример: считаем нагрузку до схемы
Ситуация учебная. Команда делает сервис отслеживания посылок: клиент вводит трек-номер и видит историю статусов, склады и курьеры присылают события «принята», «в пути», «вручена». Допустим, на вопросы о требованиях ответили так: миллион новых посылок в сутки, шесть событий на посылку, три миллиона клиентов в день проверяют статус по восемь раз, новый статус может появиться через минуту, история хранится год.
Чтений выходит 24 млн в сутки; в сутках 86 400 секунд, значит, в среднем около 280 запросов в секунду, а при вечернем пике впятеро выше среднего — около 1400. Записей 6 млн в сутки, примерно 70 в секунду. При событии в 200 байт за год копится около 440 ГБ без индексов и реплик.
Из цифр следуют решения. Между двумя событиями одну посылку открывают в среднем четыре раза, поэтому кеш со сбросом по новому событию снимет с базы около трёх четвертей чтений. Поток записей укладывается в один сервер базы, так что шардирование на старте преждевременно. Минутная задержка разрешает принимать события через очередь.
Кеш, реплики, очереди и шарды
Каждый приём снимает одну проблему и приносит свою цену. Кеш отдаёт повторные чтения, но рискует показать устаревшие данные, а при промахе тысячи запросов могут одновременно пойти в базу за одним ключом — это называют cache stampede. Реплики разгружают основную базу, но отстают: курьер, отметивший вручение, увидит старый статус, если читать с реплики, поэтому собственные изменения читают с основной базы.
Брокер сообщений отделяет приём событий от обработки: склад не ждёт, пока сервис обновит базу и отправит пуш. Брокеры обычно доставляют «хотя бы один раз», и обработчик должен спокойно переносить повторы. Шардирование делит данные по ключу между базами; для посылок ключ — трек-номер, а ключ по дате отправил бы все свежие записи в один шард. Перенос данных между шардами дорог, поэтому к нему приходят, когда расчёт этого требует.
Почему считают хвост, а не среднее
Средняя задержка скрывает самое важное. Джефф Дин и Луис Баррозу из Google в статье «The Tail at Scale» (Communications of the ACM, 2013, т. 56, № 2, DOI 10.1145/2408776.2408794) разбирают пример: сервер обычно отвечает за 10 мс, но его 99-й перцентиль — одна секунда. Если запрос обслуживает один такой сервер, медленным окажется один запрос из ста. Если ответ собирается параллельно со 100 серверов, дольше секунды будут ждать уже 63 % пользовательских запросов.
Число 63 % получается как 1 − 0,99¹⁰⁰: каждый параллельный вызов добавляет шанс нарваться на медленный ответ. Если страница посылки собирается из пяти сервисов и каждый тормозит в 1 % случаев, медленной будет примерно каждая двадцатая страница. Поэтому требования к скорости записывают в перцентилях (p99), а на схеме считают, сколько вызовов порождает один запрос. В той же статье описаны «страхующие» запросы: в тесте на BigTable копию запроса отправляли другому серверу, если ответа не было 10 мс, и 99,9-й перцентиль чтения 1000 значений со 100 серверов упал с 1800 до 74 мс ценой 2 % дополнительных запросов. Так можно повторять только чтения и идемпотентные операции.
Согласованность и отказы: CAP без лозунга
Теорему CAP часто пересказывают как «выберите два из трёх». Но разрыв сети в распределённой системе не выбирают — он случается, и настоящий выбор встаёт в этот момент: отказать части запросов, чтобы не отдать устаревшие данные, или ответить тем, что есть. Для статуса посылки допустимо второе, для списания наложенного платежа — только первое; один сервис может выбирать по-разному для разных операций.
Отказы закладывают в схему заранее: таймаут на каждом сетевом вызове, повторы с растущей паузой и случайным разбросом, предохранитель (circuit breaker), который перестаёт звать упавшую зависимость. Разумная деградация для посылок — показать статус из кеша с временем обновления. Проверку таких сценариев намеренными сбоями разбирают отдельно, в хаос-инжиниринге.
Внутри сервиса: слои, SOLID и чистая архитектура
Чистая архитектура Роберта Мартина держится на правиле: зависимости в коде направлены внутрь, к бизнес-правилам. В сервисе посылок внутри — домен с правилом «вручённую посылку нельзя вернуть в путь», над ним сценарии «зарегистрировать событие» и «выдать историю», снаружи адаптеры: HTTP-обработчик, репозиторий PostgreSQL, клиент Redis. Сценарий знает интерфейс хранилища, а не PostgreSQL, поэтому кеш добавляют декоратором вокруг репозитория, не трогая логику, а сценарии тестируют без базы. Это принцип инверсии зависимостей из SOLID в действии. Обратная ловушка — пять файлов и три интерфейса на сервис из одной таблицы: слои окупаются там, где правила сложные и будут меняться.
В каком порядке осваивать
Порядок идёт от того, что проверяется на собственном коде, к тому, что видно только на распределённой системе. Без баз данных расчёт нагрузки остаётся абстракцией, а без расчёта разговор о шардах превращается в пересказ чужих схем.
- Слои и зависимости в своём сервисе, тесты сценариев без базы.
- Базы данных: индексы, транзакции, репликация, план запроса.
- Оценка нагрузки: запросы в секунду, объём, пик — на трёх-четырёх выдуманных системах.
- Кеш и очереди: сброс кеша, идемпотентные обработчики.
- Шардирование, согласованность, перцентили, таймауты и повторы.
- C4-схема для задачи с работы и разбор с коллегой.
Для плотной тренировки подойдёт курс «Системный дизайн» от Karpov Courses: за пять недель проходят сбор требований и оценку нагрузки, высокоуровневый дизайн, масштабирование с кешированием, репликацией и поисковыми индексами и защищают финальный проект. Заданий около 80, практика на удалённом сервере, цена на странице — 47 000 ₽ при полной 66 000 ₽. Преподаватели — специалисты по машинному обучению, так что бэкендеру стоит спросить, сколько разборов классических веб-систем.
Упражнения и типичные ошибки
Возьмите знакомый продукт — чат или ленту — и за час пройдите цикл: требования, расчёт, схема, узкие места. Сверьте оценку запросов в секунду с метриками сервиса, над которым работаете. Прогоните нагрузочный тест учебного сервиса с кешем и без и смотрите на p99, а не на среднее; остановите реплику посреди теста.
Типичные ошибки: начинать с технологий, а не с вопросов; считать среднюю нагрузку и забыть о пике; шардировать систему, которой хватает одной базы; добавить кеш без плана сброса; забыть, что брокер доставит событие дважды.
Секция system design на собеседовании
Задание звучит коротко: «спроектируйте сервис отслеживания посылок». Проверяют ход рассуждения, поэтому держитесь последовательности: требования, оценка нагрузки, высокоуровневая схема, углубление в один-два компонента по выбору интервьюера, узкие места и отказы. Допущения проговаривайте вслух и записывайте — интервьюер поправит их раньше, чем на них вырастет схема. От мидла обычно ждут уверенного базового дизайна, от сеньора — глубины в компромиссах, хотя планка в компаниях разная.
Как навык влияет на доход
Отдельной надбавки за system design обычно нет: навык работает как допуск к задачам и следующему грейду. Разницу между уровнями видно в калькуляторе зарплат «Хабр Карьеры»: в октябре 2026 года по всей IT-сфере России он показывал 167 000 ₽ для middle и 286 000 ₽ для senior по 41 239 анкетам. Для бэкенд-разработчиков там указано 248 333 ₽ по 7 567 анкетам, а разбивка по уровням без регистрации скрыта. Это зарплаты, которые сообщили сами специалисты, а не предложения работодателей; период расчёта на странице не указан. Для своей оценки отфильтруйте калькулятор по городу и проверьте, где в вакансиях проектирование стоит в обязательных требованиях.
Как выбрать обучение
Если не хватает архитектуры кода и умения обосновать решение, посмотрите курс Слёрма «Архитектура приложений: от идеи до архитектурного решения»: два месяца по шесть часов в неделю, UML и C4, SOLID, чистая архитектура, многослойная, микросервисная и событийная архитектуры. Студент готовит два-три архитектурных решения и защищает проект, можно на своём рабочем кейсе. Нужны опыт разработки или аналитики, Docker, Kubernetes и REST; цена — от 45 000 до 85 000 ₽.
При сравнении программ проверьте, разбирают ли компромиссы, а не только каталог паттернов, кто проверяет ваши решения и можно ли проектировать свою систему без раскрытия конфиденциальных данных.
Для фундаментальной подготовки есть магистратура «Бэкенд-разработка и архитектура программных систем» от Нетологии и НИУ ВШЭ: около двух лет, 25–30 часов в неделю, 305 000 ₽, поступление по диплому о высшем образовании и конкурсу портфолио. В программе Go, Java, Rust, SQL и NoSQL, gRPC, микросервисы, Docker и Kubernetes, больше пяти проектов; подробного плана по проектированию систем на странице нет — запросите его до поступления.
Интенсив быстро подготовит к собеседованию, магистратура даст широкую базу за два года. Если вы уже мидл, начните с расчёта и схемы для сервиса, который поддерживаете: пробелы в таком разборе подскажут, какая программа нужна.
Сравнить онлайн-школы по цене, практике и поддержке можно в рейтинге онлайн-школ по бэкенд-разработке — это широкий рейтинг по всему направлению, а не по system design, поэтому программы из него проверяйте по требованиям к опыту и проектным заданиям.