Антиошибка недели: ставить уведомление о снижении цены как «ещё один крон», а не как часть событийной схемы.

Антиошибка недели: ставить уведомление о снижении цены как «ещё один крон», а не как часть событийной схемы.

У себя в проектах я бы делал это так: товар попадает в вишлист → в системе фиксируется текущая цена и время → дальше по расписанию или по событию обновления каталога сравниваем новую цену с последней сохранённой → если цена упала, уходим в SMS-API и отправляем оповещение 📩

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

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

И да, SMS здесь часто полезнее почты: цена изменилась — сообщение должно дойти быстро, без зависимости от inbox. Для e-commerce это не «фича ради фичи», а прямой возврат пользователей в корзину.