Проектирование высоконагруженных систем: как посчитать нагрузку и что ломается первым

Единого порога нет, и любой, кто называет точное число, продаёт услугу. Практический ориентир по уровням:

Считается это на салфетке, и без такого расчёта архитектуру обсуждать бессмысленно.

Шаг 1 — активные пользователи. Сколько людей пользуется сервисом в сутки. Для нового продукта берётся план по маркетингу, а не мечта.

Шаг 2 — действия на пользователя. Сколько экранов и запросов делает один человек за сессию. Отдельно считаются запросы к API от мобильного приложения: их обычно в разы больше, чем кажется.

Шаг 3 — коэффициент пика. Суточные запросы делятся не на 86 400 секунд, а на реальное окно активности. Для сервиса с вечерним пиком коэффициент к среднему — от трёх до десяти; для распродажи или эфира — десятки.

Шаг 4 — целевое время ответа. 200 миллисекунд на API-запрос и 2 секунды на страницу — разные бюджеты по архитектуре и деньгам.

Шаг 5 — данные. Объём базы через год, размер медиа, срок хранения истории. Часто именно рост данных, а не запросы, требует шардирования.

Итог расчёта — четыре числа: пиковые запросы в секунду, целевой отклик, объём данных на горизонте года и допустимое время недоступности. С ними уже можно спорить об архитектуре предметно, а не «давайте сделаем масштабируемо».

Порядок почти всегда один и тот же, и это не про мощность сервера.

База данных. Тяжёлые запросы без индексов, блокировки при массовых обновлениях, счётчики в одной строке, полнотекстовый поиск по таблице на десятки миллионов записей.

Запросы в цикле. Классический N+1: страница дёргает базу по разу на каждый элемент списка. На тестовых данных незаметно, на реальном каталоге — сотни запросов на одну страницу.

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

Синхронные вызовы наружу. Оплата, доставка, склад, СМС: внешний сервис отвечает медленно, ваши потоки заняты ожиданием, очередь запросов растёт, всё стоит.

Состояние в памяти процесса. Сессии и корзины, лежащие в одном инстансе, не дают добавить второй сервер: пользователя перекидывает и он теряет данные.

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

Найти узкое место без данных нельзя, поэтому начинается всё не с переписывания, а с профилирования. В проектах, которые мы подхватываем, аудит кода и архитектуры обычно показывает, что до 80% просадки дают несколько запросов и отсутствие кеша — их правят за дни, а не за месяцы.

Вертикальное масштабирование — самое простое и до определённого предела самое разумное решение: больше памяти и быстрее диски дают кратный рост без переписывания кода. Предел наступает, когда упирается запись — её нельзя размножить репликами.

Дальше три шага, по возрастанию цены:

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

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

Шардирование. Данные делятся на независимые части, у каждой свой мастер. Это меняет и схему, и код: появляется ключ шардирования, кросс-шардовые запросы становятся дорогими, а транзакции между шардами — отдельной задачей.

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

Кеш — самый быстрый способ снять нагрузку и самый быстрый способ получить новый класс проблем.

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

Главная проблема — инвалидация. Данные изменились, а в кеше лежит старая версия. Стратегия выбирается осознанно: срок жизни, сброс по событию, версионирование ключей. Универсального ответа нет, но «кешируем на час и надеемся» — не стратегия.

Холодный старт. После перезапуска или сброса кеш пуст, и вся нагрузка падает на базу — ровно в тот момент, когда она меньше всего этого ждёт. Лечится прогревом заранее.

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

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

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

Что даёт очередь под нагрузкой: сглаживает пики, потому что задачи копятся и обрабатываются с постоянной скоростью; изолирует сбои, потому что упавший внешний сервис не роняет ваш интерфейс; позволяет масштабировать обработчики отдельно от веб-части.

Чем платите: усложняется логика (пользователь не видит результат сразу), нужны понятные статусы, обработка повторов и мёртвых сообщений, мониторинг длины очереди. Асинхронность — это не «поставили RabbitMQ», а проектирование поведения продукта.

Из практики: у B2B-дистрибьютора алкоголя мы держим обмен с хранилищем данных на RabbitMQ и Go с отликом меньше полусекунды, а у «Радиоэлементов» с 500 тысячами позиций конструктор парсеров прайс-листов обрабатывает файл поставщика за 30–120 секунд вместо часов ручной работы — это тоже фоновая обработка, просто в промышленном масштабе. Техническая сторона обменов между системами разобрана в материале про интеграционную шину.

Самая недооценённая часть проектирования. Любая система имеет предел, и вопрос не в том, наступит ли он, а в том, как система себя поведёт.

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

Отключение тяжёлых функций. В пик можно выключить персональные рекомендации, отчёты, экспорт, тяжёлые фильтры. Продукт беднеет на час, но работает.

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

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

Заранее подготовленные заглушки. Статическая версия каталога, кешированная главная, режим «только чтение». Их надо не придумывать в момент аварии, а проверить заранее.

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

Профиль нагрузки. Тест повторяет реальное поведение: доля чтений и записей, распределение по разделам, длина сессии. Ровный поток запросов на главную ничего не проверяет.

Метрики. Смотреть надо не среднее время ответа, а перцентили: p95 и p99. Среднее прячет ровно тех пользователей, из-за которых вы получите жалобы.

Виды прогонов. Постепенный рост до предела, длительный тест на стабильность, резкий всплеск, тест восстановления после отказа компонента.

Инструменты. В российских проектах чаще всего встречаются четыре:

Система, за которой никто не смотрит, о своих проблемах сообщит через клиентов. Минимальный набор, который закладывается в проект, а не «потом»:

• Метрики: запросы в секунду, время ответа по перцентилям, ошибки, загрузка ресурсов, длина очередей, попадания в кеш.
• Логи с идентификатором запроса, чтобы проследить путь одной операции через все сервисы.
• Трассировка — где именно в цепочке потерялись секунды.
• Алерты по симптомам, а не по всему — растёт доля ошибок, деградирует p99, копится очередь. Алерт, который срабатывает каждый день, перестают читать.
• Дежурство и порядок эскалации: кто смотрит, что делает первым, кого поднимает.
• Цели по доступности (SLO) — договорённость о том, какой уровень сбоев считается нормой. Без неё спор «работает или нет» бесконечен.

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

Обратная сторона темы, о которой подрядчики говорят редко. Преждевременное усложнение обходится дорого и замедляет разработку.

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

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

Мы говорим об этом прямо на первом звонке: если задача не требует highload-архитектуры, продавать её мы не будем.

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

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

Ориентиры по нашим работам: сложные и высоконагруженные системы начинаются от 5 млн ₽, аудит кода и архитектуры существующей системы — от 200 до 600 тыс. ₽, отдельная интеграция — от 150 тыс. до 1,5 млн ₽. Точная сумма зависит от профиля нагрузки, требований к отклику и состояния текущего кода: оценка проекта бесплатная — опишите задачу.

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

Проектировать по среднему. Средняя нагрузка за сутки не говорит ничего: система живёт или умирает в пиковую минуту.

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

Кешировать всё подряд. Без стратегии инвалидации кеш начинает отдавать неверные остатки и цены — и это дороже медленных запросов.

Забыть про идемпотентность. Повторный запрос из-за таймаута создаёт второй заказ и второй платёж; всплывает это в самый неудачный момент.

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

Оставить систему без наблюдаемости. Без метрик и трассировки инцидент разбирают по описаниям пользователей, а не по данным.

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

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

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