High‑load не для гигантов: когда пора задуматься и сколько это стоит — честный разбор на кейсах

Мы не Яндекс, но сайт всё равно тормозит. Что делать?

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

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

«Нам точно нужна высоконагруженная архитектура? Мы же не маркетплейс с миллионами посетителей…» «А сколько это будет стоить? Хотя бы примерно, чтобы понять, потянем ли мы» «И как понять, что мы уже “high‑load”, а не просто “чуть‑чуть тормозим”?»

Долгое время я отвечал каждому индивидуально, пока не понял: проблема не в уникальности запросов, а в том, что рынок перенасыщен мифами о high‑load. Одни думают, что это удел гигантов, другие — что достаточно нанять пару разработчиков и всё само заработает.

Поэтому я сел и написал этот текст — без воды, только факты, цифры и реальные примеры из нашей практики в АЙТИФОКС. Если вы сомневаетесь, нужна ли вам сложная архитектура, — эта статья для вас.

Часть 1. Что такое high‑load на самом деле (спойлер: это не про RPS)

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

В одном проекте проблемы начинаются при 500 RPS из‑за тяжёлых операций с базой данных, а в другом — при 10 000 RPS всё летает. Поэтому мы в АЙТИФОКС смотрим на совокупность параметров:

1. количество и характер запросов;
2. объём обрабатываемых данных;
3. время ответа системы;
4. нагрузка на базу данных;
5. количество внешних интеграций;
6. пиковые нагрузки;
7. требования к доступности;
8. возможность масштабирования;
9. влияние отказа одного компонента на остальные.

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

Часть 2. 5 явных признаков, что ваша архитектура уже «на пределе»

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

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

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

Пример из практики: Инвестиционная платформа, где страницы грузились по 20–60 секунд. После переработки критичных запросов к БД и API время сократилось до 200–500 мс — ускорение в 50+ раз.

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

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

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

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

Решения:

1. разделить операции;
2. поставить тяжёлые задачи в очередь;
3. использовать кэширование;
4. вынести ресурсоёмкие задачи в отдельные сервисы.

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

RPS — не единственный показатель. В нашем проекте Proxy API один запрос содержал 200–300 МБ данных и сотни тысяч сущностей. Обрабатывать это через legacy‑ядро было рискованно, поэтому мы сделали отдельный high‑load слой на gRPC.

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

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

Часть 3. Мифы о high‑load: почему микросервисы — не панацея

Многие думают: «У нас проблемы с нагрузкой — надо переходить на микросервисы». Это заблуждение.

Микросервисы — это всего лишь инструмент, и он подходит не всем. Они полезны, когда:

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

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

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

Реальный пример: интернет‑магазин «УютСтрой» с каталогом на 180 000 товаров и синхронизацией с 1С. Мы не переписывали монолит, а вынесли обмен с 1С в отдельный сервис с очередью RabbitMQ. Время обновления каталога сократилось с суток до 15 минут — ускорение в 96 раз.

Часть 4. Сколько это стоит? Реальные ориентиры

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

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

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

Часть 5. Как работает разработка high‑load системы

Мы придерживаемся чёткой последовательности, чтобы не потратить бюджет впустую.

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

Измеряем:

1. самые тяжёлые операции;
2. точки задержек;
3. объём данных;
4. обычную и пиковую нагрузку;
5. узкие места;
6. влияние внешних сервисов;
7. требования к доступности.

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

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

На основе данных решаем:

1. нужны ли микросервисы или достаточно оптимизации;
2. где применить очереди (RabbitMQ, Kafka);
3. что кэшировать (Redis);
4. как масштабировать БД (репликация, шардирование);
5. как изолировать компоненты для отказоустойчивости.

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

В первую очередь делаем то, что влияет на скорость и надёжность: API, очереди, кэш, новый слой работы с БД.

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

Проверяем:

1. RPS;
2. время ответа (p50, p95, p99);
3. процент ошибок;
4. загрузку CPU и памяти;
5. поведение при резких пиках;
6. восстановление после сбоев.

Целевые показатели — свои для каждого проекта.

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

Постоянно следим за временем ответа, ошибками, нагрузкой, состоянием БД, очередями и доступностью. High‑load — это не архитектура «спроектировал и забыл». Нагрузка и продукт меняются, поэтому система требует постоянного внимания.

Часть 6. Как выбрать подрядчика (чтобы не выбросить деньги на ветер)

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

1. Просите конкретные кейсы

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

2. Спрашивайте про опыт с legacy

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

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

Если единственный аргумент — «так современнее» — это красный флаг. Решение должно быть обосновано характером нагрузки.

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

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

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

Если подрядчик предлагает архитектуру до изучения вашей нагрузки — задумайтесь.

Итог: главный принцип

High‑load архитектура нужна не тогда, когда вы достигли какого‑то магического числа RPS. Она нужна, когда текущая система перестаёт справляться: тормозит, работает нестабильно или не даёт бизнесу расти.

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

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

Наши реальные кейсы — цифры и факты

Вам осталось только решить, готовы ли вы к росту

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

А если остались вопросы — мы всегда на связи. В АЙТИФОКС мы специализируемся на высоконагруженных системах и помогаем бизнесу расти без боли.

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