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

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

Найдите интеграции на пути пользователя

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

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

Ограничьте время ожидания

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

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

Разделите приём данных и уведомление

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

Фоновая обработка требует собственного хранения состояния, контроля очереди и обработки ошибок. Без них проблема просто исчезнет из браузера и станет незаметной для команды. У каждого задания должны быть идентификатор, число попыток и итог. Для формы практические проверки описаны в статье о доставке заявок.

Повторяйте операции безопасно

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

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

Предусмотрите временное ограничение функции

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

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

Изолируйте перегруженную зависимость

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

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

Проверьте отказ до настоящей аварии

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

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

Если внешняя интеграция регулярно задерживает ваш сайт, напишите в HOMEWEB. Укажите сервис, затронутую операцию и пример времени сбоя — обсудим диагностику и возможные изменения обработки.