Горизонтальное масштабирование добавляет экземпляры: агенты готовят код к совместной работе

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

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

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

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

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

Согласовать нужно и поведение кэша. Документация Next.js для самостоятельного размещения отдельно требует согласовать ключ Server Functions, версии сборки и обновление кэша между экземплярами. Это пример требований фреймворка, не описание размещения нашего сайта.

Фоновое задание требует отдельного правила владения работой. Если каждый экземпляр запускает свою рассылку по расписанию, добавление реплик создаёт конкурирующие отправки. Балансировщик веб-запросов этим не управляет.

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

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

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

Подключения к БД складываются по всем экземплярам. В PostgreSQL их общий предел задаёт max_connections. Настройку пула приложения проверяют вместе с числом реплик, иначе расширение приложения забирает оставшиеся подключения.

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

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

Инженер ведёт машину агентов на vibecoding.ru: ставит задачи и принимает работу. Число коммитов подтверждает разработку, но не показывает предел нагрузки. Для этого материала полезны уроки согласования выпуска и проверки контрактов.

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

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

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

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

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

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

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

Работы по выбранной схеме можно вести через разработку по подписке. «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026; в потоке одна задача в работе. Ресурсы для работы самого продукта оплачивает заказчик.

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

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

1. Горизонтально добавляют экземпляры. До покупки проверьте, умеет ли приложение разделять работу.

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

3. Повтор задания возможен. Проверьте, что он не создаёт повтор результата.

4. Общие зависимости остаются общими. Измерьте БД и внешние сервисы вместе с приложением.

5. Схему выбирает CTO. Агентам передают отдельные правки с критериями, а прирост подтверждают повторным прогоном.