Высоконагруженные системы: архитектура для пиковых нагрузок в e-commerce

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

3 сентября 2026 Технологии 17 мин чтения

---

Что такое высоконагруженная система и когда магазин ею становится

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

Сразу договоримся о двух обозначениях. Запросов в секунду (в отчётах — RPS) — сколько обращений система обрабатывает за секунду. Время ответа на уровне 95-го процентиля (p95) — значение, быстрее которого обрабатываются 95 запросов из 100. Среднее скрывает беду: при среднем в 200 миллисекунд каждый двадцатый покупатель может ждать пять секунд, и уходят как раз эти люди.

Деловой перевод такой: система становится высоконагруженной не когда «много народу», а когда у неё пропал запас. Проверяется это одним вопросом — что произойдёт, если завтра трафик утроится на два часа. Если ответа нет, система уже работает на пределе, а пик пока не наступал.

У пиковой нагрузки в интернет-магазине три особенности, которых нет у равномерной:

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

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

Что бизнес теряет за час недоступности в распродажу

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

Третья потеря — задвоенные операции. Когда страница долго не отвечает, покупатель нажимает «Оплатить» второй и третий раз. Без защиты от повторов это даёт несколько заказов и списаний, а дальше — возвраты, обращения в поддержку и споры с банком.

Масштаб потерь зависит от доли мобильного канала. В кейсе Gulliver Family через приложение проходит 80% мобильного трафика, и оно даёт 50% общего дохода ритейлера. Когда половина выручки идёт одним каналом, час его недоступности в пиковый день — это не техническая неприятность, а вычет из плана месяца.

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

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

Профиль пика: четыре фазы распродажи

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

Самый резкий всплеск создаёт не реклама, а собственная база. Массовое уведомление доставляется за считанные минуты, и весь входящий поток приходится на одно и то же место каталога. Лечится это на стороне отправки: рассылка дробится на группы с интервалом, а не уходит одним пакетом. Как устроены сами уведомления — в разборе пуш-уведомлений в приложении, настройка сценариев — в услуге push-уведомлений.

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

Архитектура пиковых нагрузок: семь слоёв

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

1. Раздача статики и изображений через сеть доставки контента

Сеть доставки контента (CDN) — распределённые серверы, которые отдают неизменяемые файлы из точки, ближайшей к покупателю. Картинки каталога, стили, скрипты и шрифты не должны доходить до вашего сервера вообще: изображения дают основную часть переданных байтов, и их вынос — самое дешёвое действие из всего списка.

2. Промежуточное хранилище готовых ответов

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

3. Разделение чтения и записи в базе данных

База данных — самое дорогое место в системе и почти всегда конечная точка отказа. Стандартный приём: основная копия принимает записи, несколько копий-реплик отвечают на чтение. Каталог, поиск и карточки уходят на реплики, заказы — на основную копию. Цена решения — задержка синхронизации: для каталога она приемлема, для статуса оплаты нет, поэтому такие чтения оставляют на основной копии.

4. Очередь на запись

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

5. Резервирование остатков

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

6. Защита от повторов в заказах и платежах

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

7. Горизонтальное масштабирование без состояния

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

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

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

Восемь узких мест, где ломается чаще всего

Список собран по разборам работающих проектов, порядок примерно соответствует частоте.

1. Запросы к базе без нужных индексов. На тестовом каталоге в тысячу позиций работает, на боевом в тридцать тысяч — нет. Классика — фильтр по нескольким свойствам и сортировка по цене в большой категории.
2. Запрос в цикле. Список из шестидесяти карточек порождает шестьдесят отдельных обращений к базе за остатками или ценами. В обычный день незаметно, в пик умножается на число покупателей.
3. Синхронный обмен с учётной системой прямо в момент заказа. Магазин ждёт ответа от учёта, учёт ждёт освобождения блокировки, покупатель ждёт всех. Лечится очередью и отложенным проведением; про схему обмена — в услуге интеграции с учётной системой.
4. Внешние сервисы в критическом пути. Платёжный шлюз, расчёт доставки, рекомендации, рассылки. Если ответ ждут без ограничения по времени, чужая авария становится вашей. Нужен предельный срок ожидания и запасное поведение: усреднённый срок доставки вместо точного, а не белый экран.
5. Нет ограничения частоты запросов. В распродажу вместе с покупателями приходят сборщики цен конкурентов и боты перекупщиков. Без ограничений они занимают заметную долю мощности в самый неподходящий момент.
6. Пул соединений к базе меньше, чем нужно обработчикам. Приложение масштабировали, копий стало вдвое больше, а соединений к базе — столько же. Копии стоят в очереди друг за другом, и добавление серверов перестаёт помогать.
7. Журналы и аналитика пишутся синхронно. Событие аналитики, отправляемое в момент запроса, добавляет к каждому ответу задержку внешнего сервиса. В пик это заметная доля времени ответа.
8. Ручные операции в админке во время пика. Выгрузка отчёта, пересчёт категории, массовая правка цен — тяжёлые запросы к той же базе, что обслуживает покупателей. Отдельная копия для отчётов и запрет таких операций в часы акции снимают проблему организационно.

Управляемая деградация: что отключать первым

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

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

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

Нагрузочное тестирование: как узнать потолок заранее

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

Проверок несколько, и они отвечают на разные вопросы:

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

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

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

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

Метрики: какие числа держать под наблюдением

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

Последняя строка снимается не с сервера, а с устройств. Google Play собирает показатели качества с реальных телефонов, включая долю зависаний интерфейса; пороговые значения опубликованы в документации Android для разработчиков. У Apple похожие данные собираются через MetricKit.

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

Типичные ошибки подготовки к пику

• Наращивать мощность в последний день. Она помогает, когда узкое место — вычисления. Если упирается база или внешний сервис, дополнительные серверы только ускоряют подход к тому же пределу.
• Проверять только главную страницу. Главная почти всегда закеширована и держит любую нагрузку. Ломается путь оформления заказа, который в такой проверке не участвует.
• Рассчитывать, что облако справится само. Автоматическое масштабирование реагирует не мгновенно: новым копиям нужно время на запуск и прогрев, а всплеск после рассылки приходит за секунды. Обычная практика — поднять запас заранее и держать его на время акции.
• Готовить витрину и забыть про учёт. Магазин выдержал, а заказы встали в обмене с учётной системой: покупатель видит «заказ есть, статуса нет» и идёт в поддержку.
• Не проверить внешние сервисы. Партнёр может ограничить частоту обращений именно в день распродажи — у него тоже пик. Ограничения выясняются заранее, письмом.
• Не иметь плана отката. Возврат к прошлой версии должен занимать минуты и быть отрепетированным, а не обсуждаемым в момент аварии.
• Выкатывать новую версию накануне. За несколько дней до акции изменения замораживаются, кроме исправлений критических ошибок. Это скучное правило экономит больше всего нервов.
• Не предупредить людей. Служба поддержки, подрядчик по учётной системе и платёжный партнёр должны знать дату и ожидаемый объём; дежурство вокруг старта стоит дешевле разбора последствий.

Чек-лист: шесть недель до распродажи

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

1. За 6 недель. Описать критический путь покупателя: каталог, карточка, корзина, оформление, оплата, статус. Поставить цель по нагрузке — ожидаемый трафик с запасом кратности. Проверить, что метрики из таблицы выше вообще собираются.
2. За 5 недель. Собрать сценарий проверки из реальных долей поведения, подготовить среду, согласовать окно тестирования и заглушки внешних сервисов.
3. За 4 недели. Провести нагрузочную и стрессовую проверки. Получить потолок, точку деградации и перечень узких мест с приоритетом.
4. За 3 недели. Исправлять по списку сверху вниз: индексы и запросы, кеширование категорий, вынос обмена с учётом в очередь, ключ операции в оплате.
5. За 2 недели. Повторный прогон на тех же сценариях — сравнивать есть с чем. Настроить переключатели функций для уровней деградации и проверить каждый из них.
6. За 1 неделю. Заморозить изменения, отрепетировать откат, согласовать запас мощности с провайдером, назначить дежурных и написать порядок действий на одну страницу.
7. День акции. Наблюдение с первой минуты, ручное управление уровнями деградации, отказ от любых тяжёлых операций в админке.
8. Через неделю. Разбор: что сработало, где был запас, какие пункты перенести в постоянную работу. Этот шаг пропускают чаще всего, а он делает следующую акцию дешевле.

Кто это делает и из чего складывается смета

Работа делится на две части. Первая — обследование: замер, разбор узких мест, отчёт; объём понятен заранее, поэтому его обычно берут фиксированной суммой (Fixed Price). Вторая — доработки: их состав ясен только по итогам обследования, и считаются они по фактическим часам и ролям (Time & Materials).

Если систему приходится не чинить, а строить заново, вопрос смещается к модели владения. Модель FITTIN состоит из трёх частей. Первое — единоразовая интеграция платформы под бренд, до 30 рабочих дней (для направления «мобильное приложение» по тарифу ПРО — от 525 000 ₽). Второе — ежемесячные лицензионные платежи (от 150 000 ₽/мес по тому же тарифу), в которые уже включены все затраты на техническую поддержку команды FITTIN: отдельная команда разработки для этого не нужна. Третье — новый функционал и доработки, которые считаются отдельно по Time & Materials с оценкой по часам перед стартом задачи. Полная таблица направлений и тарифов — на странице тарифов, сравнение подходов к владению — в материале о стоимости владения готовым решением и модульной платформой.

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

Серверная часть у нас делается на Python: разработка на Django для крупных каталогов и админок, разработка на FastAPI — для программных интерфейсов с высокой долей одновременных запросов. Клиентская часть собирается из одной Flutter-кодовой базы: сайт интернет-магазина и приложение для App Store, RuStore и Google Play живут на одном коде — такой подход убирает расхождения в поведении каналов под нагрузкой. Как устроена сама платформа — в описании модульной платформы для e-commerce и в услуге комплексной разработки интернет-магазина.

Кейсы: где нагрузка была частью задачи

Ниже — проекты, где объём каталога, доля канала или сценарий покупки сами задавали требования к устойчивости. Метрики взяты со страниц кейсов.

Ещё один срез — регулярность выпусков. В кейсе Street Beat за пять месяцев после запуска приложение органически привлекло 130 000 новых пользователей, а команда закрыла 700+ задач и выпустила 7 релизов. Сезонность российского онлайн-ритейла регулярно разбирает Data Insight. Остальные проекты — в разделе кейсов.

Итог: архитектура пиковых нагрузок на одной странице

Пик не проверяет мощность серверов — он проверяет запас и подготовку. Короткий порядок действий:

1. Сначала измерение, потом решения. Узкое место находится замером, а не обсуждением.
2. Снимайте нагрузку слоями сверху вниз. Сеть доставки контента и кеш ответов дают больше всего при меньших затратах; база данных — последний рубеж, а не первый.
3. Разделяйте чтение и запись. Каталог живёт на репликах и в кеше, заказы идут через очередь с ключом операции.
4. Готовьте не только витрину. Учётная система, платёжный шлюз и служба доставки — часть вашего пика, даже если они не ваши.
5. Заранее решите, что отключать. Четыре уровня деградации и переключатели к ним стоят дешевле, чем один час недоступности.
6. Замораживайте изменения перед акцией и повторяйте замеры перед каждым выпуском — иначе запас уходит на новые функции.

Что делать дальше:

• Узнать свой потолок до распродажи — нагрузочное тестирование; понять состояние кода — аудит кода или комплексный аудит интернет-магазина.
• Усилить команду на сезон — backend-разработчики, DevOps-инженеры, QA-инженеры; передать сопровождение — техническая поддержка приложений.
• Посмотреть, как устроены наши решения для торговли — мобильные приложения для e-commerce, сайты интернет-магазинов, Flutter для e-commerce, B2B-приложения для юридических лиц.
• Зафиксировать требования к нагрузке до старта работ — разработка технического задания; посчитать порядок бюджета — калькулятор стоимости; описать задачу — контакты.

Вопросы и ответы

Поможет ли более мощный сервер?

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

Успеет ли автоматическое масштабирование в облаке?

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

За сколько недель до распродажи начинать подготовку?

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

Можно ли подготовиться к пику без доступа к исходному коду?

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

Что делать, если под нагрузкой падает не сайт, а учётная система?

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

Нужно ли переписывать систему, если она не держит пик?

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

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.