Пик нагрузки ломает обмен: как выдержать интеграцию в горячий сезон

В обычный вторник обмен сайта и 1С выглядит безобидно: заказ ушёл, остаток обновился, статус доехал. В Black Friday или в последние дни квартала картина другая. Очередь растёт, блокировки в учётной системе множатся, витрина начинает отвечать таймаутами на создание заказа. Формально «интеграция есть». Фактически в пик она становится узким горлом всей коммерции.

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

Как ломается обмен сайт ↔ 1С под нагрузкой

Синхронный вызов в момент оформления. Пользователь жмёт «оформить», сайт ждёт ответ 1С по остаткам, резервированию или проведению. 1С отвечает дольше, PHP-воркеры заканчиваются, новые покупатели видят ошибку ещё до кассы.

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

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

Повторные ретраи без идемпотентности. Таймаут — клиент жмёт ещё раз, сайт шлёт ещё один заказ, 1С получает дубли. Потом сутки разбирают «лишние» документы.

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

Почему «просто усилить сервер» часто не помогает

Добавить CPU 1С или ещё один PHP-инстанс можно. Но если архитектура обмена — синхронная и болтливая, вы лишь отложите потолок. Узкое место переезжает: с CPU на блокировки, с блокировок на сеть, с сети на лицензии и сеансы.

Пик ещё и неравномерен. Минута тишины, затем волна. Без очереди и ограничения скорости волна бьёт напрямую в учётную систему. Учётная система хорошо считает документы; она плохо заменяет брокер сообщений.

Рабочие подходы: очереди, лимиты, асинхронность

Разделяют «принять заказ на сайте» и «провести его в 1С». Пользователь получает подтверждение после локально согласованной транзакции сайта; обмен уходит в очередь с гарантией доставки и понятным статусом «в обработке / проведён / ошибка».

Вводят rate limit и квоты: сколько документов в минуту можно отправлять в 1С, сколько потоков параллельно, какие операции приоритетнее. Фон уступает место живому заказу.

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

Добавляют backpressure: если потребитель отстаёт, производитель замедляется или переключается в режим деградации (упрощённое резервирование, отложенное проведение), вместо молчаливого роста бездонной очереди.

Наблюдают бизнес-метрики обмена: глубина очереди, лаг, доля ошибок, время до проведения, число дублей. Алерт должен сработать до того, как витрина «встала».

Типовые ошибки интеграций «для среднего дня»

Проектировать обмен только под happy path. Пик — это не happy path; это штатный режим для e-commerce и дистрибуции в конце периода.

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

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

Чинить пик только людьми: «пусть операторы проводят вручную». В моменте спасает, системно закрепляет хрупкость.

Не проводить игровой прогон на копии с профилем Black Friday. Без репетиции первый настоящий пик и есть нагрузочный тест — на деньгах клиентов.

Ещё одна ловушка — «оптимизация» синхронными пачками без лимита размера. Сайт пытается за один запрос отдать в 1С сотни позиций или статусов. В спокойный день проходит. В пик такой запрос держит блокировки дольше, чем живёт терпение покупателя на checkout. Дробить payload, ограничивать размер пачки и ставить таймауты с понятным повтором — такая же часть устойчивости, как очередь.

Наконец, забывают про людей. Даже идеальный брокер не спасёт, если в ночь распродажи нет владельца интеграции с правом включать деградацию и чистить DLQ. Регламент должен быть коротким: кто смотрит дашборд, кто звонит 1С-админу, при каком лаге останавливают фоновые обмены.

Чек-лист перед сезоном и закрытием периода

• Карта потоков: что синхронно, что асинхронно, что можно отложить.
• Очередь с метриками лага, DLQ для ядовитых сообщений, регламент повторной обработки.
• Rate limit и лимит параллелизма в сторону 1С; приоритет живых заказов.
• Идемпотентность на создание заказа, оплату, изменение статуса.
• Сценарий деградации: что отдаём пользователю, если учёт отстаёт.
• Нагрузочный прогон на копии с пиковым профилем, не «средним днём».
• Алерты до витрины: очередь, ошибки, время проведения.
• Согласованный канал эскалации между сайтом, 1С и бизнесом на время акции.

Частые вопросы

Очередь не замедлит отражение остатков? Немного — да. Но предсказуемая задержка лучше хаотичных таймаутов и двойных заказов. Для критичных SKU делают ускоренный путь или короткое локальное резервирование.

Можно ли обойтись только масштабированием 1С? Иногда да на коротком горизонте. Если обмен синхронный и болтливый, потолок всё равно наступит — лучше совместить мощность с архитектурными ограничителями.

Что важнее на старте: очередь или rate limit? Обычно оба. Очередь защищает пользователя от ожидания 1С; rate limit защищает 1С от шторма.

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

Нужно ли переписывать всю интеграцию? Не всегда. Часто достаточно вынести узкое место checkout из синхронного вызова и поставить дисциплину повторов. Полная переработка — если обмен давно превратился в клубок скриптов без владельца.

Следующий шаг

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