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

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

В этой статье разберём, когда бизнесу нужна разработка высоконагруженного сервиса, из чего состоит такая архитектура (high-load), как идёт разработка и сколько она может стоить. И главное — покажем реальные примеры высоких нагрузок на проектах АЙТИФОКС.

Короткий ответ: high-load — это система, которая должна стабильно работать при значительной или неравномерной нагрузке на инфраструктуру, данные и отдельные сервисы.

При этом универсального значения RPS (количество запросов в секунду), после которого система автоматически становится высоконагруженной, не существует.

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

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

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

Как высокая нагрузка выглядит на практике

В проектах АЙТИФОКС мы сталкивались с разными сценариями:

• На инвестиционной платформе страницы из-за архитектурных проблем и неоптимальной работы с данными загружались 20–60 секунд. После переработки критических запросов к БД и API время загрузки удалось сократить до 200–500 мс — это более чем в 50 раз.
• В другом проекте через Proxy API в отдельных сценариях проходили сотни тысяч сущностей и 200–300 МБ данных за один запрос. API проектировался как отдельный high-load слой, чтобы не создавать дополнительную нагрузку на критичное legacy-ядро. Сам Proxy API реализован на gRPC.
• А интернет-магазину «УютСтрой» необходимо работать с каталогом на 180 000 товаров и 800+ заказами в день и постоянно синхронизировать данные с 1С.

Поэтому в АЙТИФОКС мы не определяем high-load по одной цифре RPS. Сначала смотрим, где система упирается в ограничения и какая нагрузка критична именно для конкретного бизнеса.

1. Самые важные операции начинают тормозить

Не обязательно тормозит вся система целиком. Проблемы могут возникать только в отдельных местах:

• оформление заказа;
• оплата;
• поиск;
• формирование отчёта;
• загрузка большого массива данных;
• синхронизация с внешней системой.

В уже упомянутом примере с инвестиционной платформой главной проблемой была именно скорость работы с данными: страницы грузились по 20–60 секунд. После того как мы переработали API и самые важные запросы к базе данных, время загрузки сократилось до 200–500 миллисекунд — то есть стало в десятки раз быстрее.

→ Кейс: как АЙТИФОКС перезапустил инвестиционную платформу и ускорил её работу более чем в 50 раз. 

2. Пиковая нагрузка регулярно превращается в проблему

Распродажи, массовые рассылки, старт продаж билетов, публикация результатов или другие события могут резко увеличивать количество запросов.

Если команда заранее знает дату пика и всё равно готовится работать в режиме ЧП — архитектуру стоит проверить.

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

3. Одна тяжёлая операция влияет на всю систему

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

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

Решить проблему можно несколькими способами:

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

4. Объём данных становится проблемой сам по себе

RPS (количество запросов в секунду) — далеко не единственный показатель нагрузки.

Вернёмся к проекту Proxy API, о котором говорили выше. Один запрос мог содержать 200–300 МБ данных и сотни тысяч сущностей. Обрабатывать такие объёмы напрямую через legacy-ядро было рискованно: это увеличивало задержки и могло влиять на стабильность критической системы.

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

→ Кейс: как АЙТИФОКС открыл legacy-ядро на Java для новых продуктов без переписывания системы.

5. Рост бизнеса требует всё больше ручного вмешательства

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

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

Единого универсального набора технологий не существует. Всё зависит от того, какая именно нагрузка и какие ограничения у конкретной системы.

Но чаще всего при построении высоконагруженных систем используют такие подходы и инструменты:

• Горизонтальное масштабирование — добавление новых серверов, чтобы распределить нагрузку между ними.
• Вертикальное масштабирование — увеличение мощности одного сервера: больше процессоров, памяти, быстрее диски.
• Балансировка нагрузки — специальный механизм, который равномерно распределяет входящие запросы между несколькими серверами, чтобы ни один не перегружался.
• Кэширование — сохранение часто используемых данных в быстрой памяти, чтобы не обращаться каждый раз к медленной базе данных.
• Очереди сообщений — способ выполнять тяжёлые или долгие задачи по очереди, не блокируя основную работу системы.
• Оптимизация и масштабирование базы данных — настройка и разделение базы, чтобы она быстрее искала и обрабатывала данные даже при больших объёмах.
• Репликация — создание копий данных на нескольких серверах. Это повышает надёжность и позволяет читать данные с ближайшей копии, снижая нагрузку на основную базу.
• Микросервисная или модульная архитектура — разделение системы на отдельные независимые части, которые можно развивать, чинить и масштабировать по отдельности.
• Мониторинг — постоянное наблюдение за состоянием системы: за нагрузкой, ошибками, временем ответа. Это помогает вовремя заметить проблему и предотвратить сбой.
• Механизмы отказоустойчивости — способы сделать так, чтобы система продолжала работать, даже если какой-то её компонент вышел из строя (например, автоматическое переключение на резервный сервер).

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

Вертикальное масштабирование — это когда вы делаете мощнее тот сервер, который уже есть: добавляете ему больше процессорной мощности, оперативной памяти или ставите более быстрые диски. То есть усиливаете одну машину.

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

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

Микросервисы — это не обязательное условие для high-load. Это всего лишь инструмент, который подходит не всем.

Они полезны, когда системе действительно нужно:

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

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

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

Пример: 180 000 товаров и интеграция с 1С

Возвращаясь к проекту «УютСтрой», о котором мы упоминали в начале: интернет-магазин работает с каталогом на 180 000 товаров и принимает 800+ заказов в день.

Одной из проблем была синхронизация большого объёма данных с 1С: обновление каталога занимало около суток.

АЙТИФОКС вынесли обмен данными с 1С в отдельный сервис и настроили передачу через очередь сообщений RabbitMQ. Каталог поступает порциями и обрабатывается без блокировки основной системы.

В результате время обновления каталога сократилось с суток до 15 минут.

→ Кейс: разработка высоконагруженного интернет-магазина «УютСтрой» на 180 000 товаров.

Очереди нужны, чтобы не выполнять все тяжёлые операции сразу, заставляя пользователя ждать.

Вместо сценария: запрос → тяжёлая операция → пользователь ждёт

можно построить: запрос → задача попадает в очередь → обрабатывается отдельно → система возвращает результат.

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

В уже знакомом нам примере с «УютСтрой» через RabbitMQ организована синхронизация большого каталога с 1С.

Другой пример — программно-аппаратный комплекс ФОТОКАССА. Его архитектура рассчитана на сеть из 100+ устройств, синхронизирующих данные с центральным сервером; для больших объёмов данных используется S3-хранилище.

→ Кейс: как АЙТИФОКС разработал программно-аппаратный комплекс ФОТОКАССА с машинным зрением.

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

• неоптимальных запросах к базе данных (SQL-запросах);
• отсутствии нужных индексов (специальных указателей, которые ускоряют поиск в базе);
• повторном выполнении одних и тех же операций;
• слишком больших объёмах данных, которые передаются между сервисами;
• неправильно работающем поиске;
• отсутствии кэширования (когда часто запрашиваемые данные сохраняются в быстрой памяти);
• неудобной или неэффективной структуре API.

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

Этап 1. Анализ нагрузки

Сначала необходимо понять:

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

Без этого невозможно выбрать правильную архитектуру.

Этап 2. Проектирование

На основе полученных данных определяем:

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

Этап 3. Разработка критических компонентов

В первую очередь делают то, что напрямую влияет на скорость и надёжность:

• новый API;
• отдельные сервисы;
• очереди сообщений;
• кэширование;
• новую схему работы с базой данных;
• слой для связи с внешними системами.

Этап 4. Нагрузочное тестирование

Тесты позволяют проверить архитектуру до того, как она столкнётся с реальными пользователями.

Обычно проверяют:

• сколько запросов в секунду выдерживает система (RPS);
• время ответа: как быстро отвечает система для 50%, 95% и 99% запросов (p50, p95, p99). Это показывает, насколько стабильна скорость;
• процент ошибок;
• загрузку процессора и памяти;
• нагрузку на базу данных;
• как система ведёт себя при резком росте нагрузки;
• как быстро восстанавливается после сбоев.

Целевые показатели для каждого проекта свои, а не берутся из общей таблицы.

Этап 5. Мониторинг после запуска

После релиза нужно постоянно следить за:

• временем ответа;
• ошибками;
• нагрузкой на серверы;
• состоянием базы данных;
• очередями;
• доступностью сервисов.

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

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

На цену влияют:

• текущее состояние системы — что уже есть и что требует доработки;
• объём данных — сколько информации нужно хранить и обрабатывать;
• обычная и пиковая нагрузка — сколько запросов приходит в обычное время и сколько в моменты всплесков;
• количество интеграций — сколько внешних сервисов и программ нужно подключить;
• требования к отказоустойчивости — насколько быстро система должна восстанавливаться после сбоев;
• безопасность — насколько серьёзная защита нужна;
• необходимость миграции — нужно ли переносить данные со старых систем;
• работа со старым кодом (legacy) — если часть системы написана давно и её нельзя просто выбросить;
• мониторинг и инфраструктура для разработки и эксплуатации (DevOps) — инструменты для наблюдения за системой и автоматизации процессов.

Ориентировочная стоимость разработки

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

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

• объём и характер запросов;
• сколько данных нужно хранить;
• исходящий трафик (сколько информации система отдаёт наружу);
• база данных;
• количество сервисов;
• резервирование (наличие резервных серверов и копий данных);
• CDN (сеть для быстрой доставки контента пользователям);
• мониторинг;
• требования к доступности (SLA — насколько быстро система должна восстанавливаться);
• облачная инфраструктура или собственные серверы

Чаще всего — нет.

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

Здесь снова вспомним пример с Proxy API. В одном из проектов АЙТИФОКС было старое ядро (legacy) на языке Java. Оно работало стабильно, но было устроено так, что новые современные продукты не могли с ним нормально взаимодействовать.

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

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

Это один из ключевых принципов работы с высоконагруженными системами:

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

Высокая нагрузка может выглядеть совершенно по-разному. В проектах АЙТИФОКС ограничением становились и скорость работы с БД, и объём одного запроса, и синхронизация большого каталога, и распределённая сеть устройств.

Это показывает, почему high-load нельзя определять только количеством запросов в секунду.

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

1. Посмотрите реальные high-load проекты

Просите не только список технологий, но и цифры:

• какая была нагрузка;
• где находилось узкое место;
• что изменили;
• какой результат получили.

2. Проверьте опыт работы с legacy

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

3. Попросите объяснить архитектурное решение

Подрядчик должен уметь объяснить, почему предлагает:

• микросервисы;
• очередь;
• кэш;
• конкретную БД;
• отдельный API;
• горизонтальное масштабирование.

Если единственный аргумент — «так современнее», этого недостаточно.

4. Спросите о нагрузочном тестировании и мониторинге

Производительность должна измеряться, а не оцениваться «на глаз».Уточните:

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

5. Обратите внимание, начинается ли работа с анализа

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

Что считается высоконагруженной системой?

Единого порога нет. High-load можно считать систему, для которой объём запросов, данных, интеграций или пиковая нагрузка становятся значимым архитектурным фактором и требуют специальных решений для сохранения производительности и доступности.

При каком RPS нужна high-load архитектура?

Универсального значения RPS не существует. Один сервис может успешно обрабатывать большое количество простых запросов, а другой испытывать проблемы при значительно меньшем RPS из-за тяжёлых операций с БД или больших объёмов данных.

Обязательно ли использовать микросервисы?

Нет. В некоторых проектах достаточно оптимизировать БД, API, кэширование или отдельные компоненты. Микросервисная архитектура оправдана тогда, когда преимущества независимого масштабирования и изоляции компонентов компенсируют дополнительную сложность.

Можно ли масштабировать существующий монолит без полного переписывания?

Да. Можно оптимизировать отдельные компоненты, внедрить кэширование и очереди, выделить наиболее нагруженные функции в отдельные сервисы или создать дополнительный интеграционный слой.

Сколько стоит разработка высоконагруженного сервиса?

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

С чего начать, если система уже тормозит?

С измерений. Нужно определить p95/p99 времени ответа, error rate, состояние БД и инфраструктуры, самые тяжёлые операции и поведение системы во время пиков.

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

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

Поэтому правильный порядок выглядит так:

измерить нагрузку → найти узкие места → определить требования → выбрать архитектурное решение → протестировать → масштабировать.

Когда возникают проблемы с нагрузкой, первый вопрос должен быть не «а не пора ли нам перейти на микросервисы?», а «где именно сейчас ограничение и какое решение поможет его убрать?».