Масштабируемая архитектура — это устройство платформы, при котором рост нагрузки закрывают добавлением ресурсов, а не переписыванием кода. Для большинства проектов это модульный монолит с чёткими границами между частями, база данных, рассчитанная на рост объёма, состояние, вынесенное из приложения, и мониторинг. Микросервисы нужны не всем: они решают задачу независимых команд и релизов, а не саму по себе нагрузку.
Коротко
Масштабируемость — это способность системы выдерживать рост нагрузки без переделки: пользователей стало больше, платформа отвечает так же быстро, просто использует больше ресурсов. Путей два, и они не заменяют друг друга.
Оговорка про состояние здесь не формальность. Пока сессии пользователей, загруженные файлы и счётчики лежат в памяти одного сервера, второй сервер не поможет: часть запросов будет попадать «не туда». Кроме того, в любой системе остаётся работа, которую нельзя разложить на несколько машин, — например, запись в одну таблицу базы данных. Эта доля и задаёт реальный предел горизонтального роста.
Приложение без состояния не хранит между запросами ничего, что нельзя потерять вместе с сервером. Методика Twelve-Factor App формулирует это прямо: процессы приложения не хранят состояние и ничего не разделяют между собой, а данные, которые должны сохраняться, лежат во внешнем сервисе — обычно в базе данных. Привязку пользователя к конкретному серверу, sticky sessions, методика называет нарушением принципа.
На практике это значит: сессии — в общем хранилище вроде Redis, загруженные файлы — в объектном хранилище, а не на диске сервера приложений, долгие операции — в очереди задач. Тогда любой сервер обрабатывает любой запрос, а вышедший из строя заменяется новым без потери данных.
Важно Проверить это можно до всякой нагрузки: запустите две копии приложения за балансировщиком и поработайте с обеих. Если пользователя выбрасывает при переключении между копиями, а загруженный файл виден только на одной, состояние ещё живёт внутри приложения.
Монолит — это платформа одним приложением: каталог, заказы, платежи и уведомления живут в общем коде и общей базе. Для старта такой вариант нормален и чаще всего оправдан. Разница между тремя подходами не в моде, а в том, какую цену вы платите за независимость частей.
| Подход | Когда подходит | Что даёт | Чем рискуете |
|---|---|---|---|
| Монолит | Первая версия продукта, одна команда, нагрузка неизвестна | Быстрый старт, простая отладка, одна база и один деплой | Со временем части срастаются, и любое изменение задевает соседей |
| Модульный монолит | Продукт растёт, команда до нескольких групп, нагрузка предсказуема | Границы между модулями заданы заранее, любой модуль можно вынести позже | Границы нужно поддерживать дисциплиной, иначе он превращается в обычный монолит |
| Микросервисы | Несколько команд с разными релизными циклами, части с резко разной нагрузкой | Независимые обновления, точечное масштабирование перегруженных частей | Сеть между сервисами, распределённые сбои, своя инфраструктура и мониторинг |
Фраза «сбой одного сервиса не роняет систему целиком» верна только при изоляции отказов: таймауты на все внешние вызовы, ограничение числа повторов, запасной сценарий на случай недоступности соседа. Без этого микросервисы дают каскадные отказы — медленный сервис удерживает соединения остальных и останавливает всю цепочку.
Разумный путь для большинства проектов — модульный монолит с чистыми границами: модули общаются через API, программный интерфейс для обмена данными, и при необходимости любой из них выносится в отдельный сервис без переписывания платформы. Как устроена серверная часть и как проектируют такие интерфейсы, разобрано в статье о бэкенде и API для мобильного приложения.
Подключают по порядку: индексы и оптимизацию запросов, кэш, отдачу статики через CDN, очереди и реплики базы для чтения. Начинать надо с самого дешёвого приёма — каждый следующий сложнее в обслуживании предыдущего, и включать их сразу все означает платить за то, чем вы пока не пользуетесь.
Автомасштабирование в облаке добавляет и убирает серверы по текущей нагрузке. Оно помогает при резких пиках, но не заменяет эти шаги: если узкое место — база данных, лишние серверы приложений только увеличат очередь к ней.
Со стороны системы смотрят на четыре показателя. Книга Google по SRE называет их золотыми сигналами: задержка (сколько занимает обработка запроса), трафик (сколько запросов приходит), ошибки (доля неуспешных) и насыщенность (насколько заполнены самые дефицитные ресурсы). Рост задержки при неизменном трафике — первый признак, что запас кончается.
Со стороны пользователя скорость измеряют по Core Web Vitals. Google задаёт пороги, при которых показатель считается хорошим, и считает результат по 75-му процентилю загрузок, отдельно для телефонов и компьютеров.
Нагрузочное тестирование проводят до пика, а не после него. Сценарии берут из реальной работы — регистрация, поиск, оформление заказа, — нагрузку поднимают постепенно и фиксируют, при каком числе одновременных пользователей растёт задержка и появляются ошибки. Полученное число становится известным пределом, а не сюрпризом в день акции.
Для соблюдения закона собственный сервер не нужен: достаточно облака в дата-центре на территории страны. С 27 марта 2026 года хранить в Узбекистане обязательно только биометрические и генетические данные и данные пользователей операторов связи — так устанавливает статья 27-1 закона о персональных данных в редакции закона № ЗРУ-1125 от 26.03.2026.
Важно Остальные персональные данные можно хранить за рубежом при одном из условий той же статьи. Разбор условий, перечня стран и задержек до зарубежных дата-центров — в статье об облаке и сервере в Узбекистане.
Собственные серверы оправданы при постоянной высокой нагрузке, когда аренда тех же мощностей за несколько лет выходит дороже покупки, или при требованиях к физической изоляции оборудования. Платформе с меняющейся нагрузкой удобнее облако: конфигурацию меняют без закупки и ожидания поставки.
Цена зависит от того, сколько ресурсов действительно нужно платформе, и от набора услуг вокруг них: резервных копий, мониторинга, защиты от DDoS и администрирования. На странице серверов и облака состав работ расписан по трём задачам.
Счёт растёт не от числа зарегистрированных пользователей, а от того, что они делают: от объёма базы и резервных копий, исходящего трафика, тяжёлых отчётов и фоновой обработки файлов. Решения, заложенные на старте, увеличивают бюджет меньше, чем переделка архитектуры под нагрузкой, когда платформа уже работает и остановить её нельзя.
Готовность к росту проверяется не размером сервера, а тем, что можно сделать без переписывания кода. Пройдитесь по списку до того, как нагрузка вырастет.
За пределами списка остаётся эксплуатация: кто дежурит при сбое, за какое время реагирует и кто обновляет систему. Без этого даже удачная архитектура не спасает — как устроена такая работа, разобрано в статье о технической поддержке IT-инфраструктуры.
Syntra Systems считает нагрузку до запуска: сколько одновременных пользователей ожидается, какой объём данных копится за год, в какие часы приходят пики и какие операции самые тяжёлые. По этим числам подбираем конфигурацию и решаем, что выносить в фоновые процессы, а после запуска пересматриваем её по фактическим показателям.
Пример На выставке UzFranchise Expo нагрузка приходилась на вход: за два дня отсканировали 3 539 QR-билетов, проверка одного гостя занимала 0,2 секунды. Такая нагрузка приходит не равномерно, поэтому запас считают по пиковым минутам, а не по среднему за день. Подробности — в кейсе выставки.
Платформу собираем модулями с чистыми границами, состояние выносим из приложения, отчётность и обработку файлов — в отдельные процессы. Размещаем в Syntra Cloud, в дата-центре на территории Узбекистана, с ежедневными резервными копиями и мониторингом доступности.
Обсудим вашу задачу
Расскажите, что нужно сделать, — оценим сроки и стоимость и предложим решение.
Нет. Небольшому продукту чаще подходит аккуратный модульный монолит: он проще в отладке и дешевле в эксплуатации. Микросервисы оправданы, когда над платформой работают несколько команд с разными релизными циклами или когда части системы нагружены совсем по-разному.
Границами. В обычном монолите любая часть кода может обратиться к любым данным напрямую, поэтому со временем изменения задевают соседей. В модульном модули обращаются друг к другу только через заданные интерфейсы и не читают чужие таблицы — тогда модуль можно вынести в отдельный сервис без переписывания платформы.
Когда у модуля появляется своя команда со своим графиком релизов, либо когда его нагрузка резко отличается от остальной платформы и его нужно масштабировать отдельно. Выносить ради архитектурной чистоты, без одной из этих причин, обычно дороже, чем оставить как есть.
Сначала измерить, а не переписывать. Журнал медленных запросов и метрики задержки показывают, где именно теряется время: в базе данных, во внешнем сервисе или в отдаче файлов. В большинстве случаев первые улучшения дают индексы, кэш и вынос тяжёлых операций в фон.
Контейнеры полезны почти всем: они делают запуск одинаковым на любом сервере. Kubernetes добавляет к этому оркестрацию множества сервисов и собственную сложность в эксплуатации, поэтому его берут, когда сервисов много и есть кому их обслуживать.
Перед запуском, перед сезонным пиком или рекламной кампанией и после крупных изменений в базе данных или интеграциях. Между этими точками достаточно мониторинга: если задержка растёт при неизменном трафике, тест стоит повторить раньше плана.
Разница на старте невелика: это вопрос порядка в коде и данных, а не дополнительных технологий. Дорого обходится обратное — переделка архитектуры, когда платформа уже работает, остановить её нельзя, а данные нужно переносить без потерь.
