пуш-уведомления не доходят: как спроектировать систему без потерь

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

Почему возникает задержка и потеря push-уведомлений

Отдел продаж московской торговой компании настроил push о смене статуса заказа — уведомление должно приходить клиенту сразу после того, как менеджер меняет статус в 1С. На практике часть клиентов получала пуш через 40-50 минут, часть не получала вовсе. Разработчик винил Firebase, менеджер — 1С, но проблема была в связке между ними.

Мобильное приложение отправляло запрос на сервер уведомлений синхронно, в том же потоке, что и обновление заказа. Если очередь FCM или APNs в этот момент отвечала медленно, весь процесс обновления заказа подвисал вместе с уведомлением. Но синхронная связка — не единственная причина. Токен устройства обновляется при переустановке приложения или смене SIM-карты, а если сервер хранит только последний токен без версионирования, часть уведомлений улетает в никуда.

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

Основные технические причины

• ✓синхронная отправка вместо очереди с воркерами
• ✓отсутствие ретраев при недоступности push-сервиса
• ✓устаревшие токены без механизма обновления
• ✓смешение приоритетных и неприоритетных уведомлений в одном канале

Как исправить архитектуру доставки уведомлений

Первый шаг — вынести отправку уведомлений в отдельную очередь. Событие «заказ готов» кладётся в очередь сообщений, а отдельный воркер забирает задачи и отправляет их через FCM или APNs с повторными попытками при ошибке. Основной процесс в 1С или на бэкенде не ждёт ответа от push-сервиса — он просто ставит задачу и продолжает работу.

Второй шаг — версионирование токенов устройств. Каждое устройство при регистрации получает не просто токен, а связку токен плюс дата обновления. Если push не доставлен, система пробует резервный канал: SMS для критичных уведомлений или уведомление внутри приложения при следующем открытии.

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

Когда уведомления завязаны на данные из 1С — остатки, статусы оплаты, готовность заказа — задержка часто рождается не в push-сервисе, а на стыке систем. Здесь помогает интеграция приложения с 1С через отдельный API-слой с очередью событий, а не прямые синхронные запросы к базе.

Что делать, если ошибка доставки повторяется после первого исправления

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

Второй частый повтор ошибки — очередь без dead letter queue. Если сообщение не доставлено после трёх попыток, оно должно уходить в отдельный список для ручного разбора, а не исчезать молча. Без этого механизма команда узнаёт о проблеме от клиента, а не из мониторинга.

Третья причина — нагрузка на сервер, который обрабатывает и push-очередь, и обычные запросы приложения одновременно. На слабом сервере в момент пиковой отправки (например, массовая рассылка об акции) обычные API-запросы начинают тормозить, а push уходят с задержкой. Здесь разделение нагрузки через аренду отдельного сервера для 1С и очереди снимает конфликт ресурсов между двумя типами трафика.

Как предотвратить проблемы с уведомлениями на этапе проектирования

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

Первое — отдельный микросервис уведомлений с собственной базой статусов доставки, не связанный напрямую с основной логикой приложения. Второе — очередь сообщений (например, на базе брокера, а не прямых HTTP-вызовов) между бэкендом и push-провайдером. Третье — таблица токенов с историей, а не одна запись на пользователя. Четвёртое — разделение каналов по приоритету с отдельными очередями. Пятое — мониторинг с алертами на рост очереди недоставленных сообщений.

Где уведомления завязаны на 1С

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

Сравнение подходов к архитектуре уведомлений

Сколько стоит спроектировать надёжную систему уведомлений

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

Когда причина задержек — не в коде, а в слабом сервере, на котором крутится и 1С, и очередь уведомлений, отдельный вариант — перенести нагрузку на выделенный сервер. Мы предлагаем разработку мобильных приложений с проектированием архитектуры уведомлений на старте проекта, включая расчёт нагрузки и выбор между push-сервисами, SMS-фоллбэком и уведомлениями внутри 1С через 1С:Мобильную платформу.

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

Почему push-уведомления приходят с задержкой в мобильном приложении?

Чаще всего задержка возникает из-за синхронной отправки уведомления в том же потоке, что и основная операция. Если push-сервис отвечает медленно, весь процесс подвисает вместе с уведомлением. Решение — вынести отправку в отдельную очередь с воркерами.

Можно ли гарантировать 100% доставку push-уведомлений?

Нет, push-протоколы FCM и APNs не гарантируют доставку — устройство может быть офлайн или уведомления отключены в настройках. Но можно снизить потери до минимума с помощью ретраев, dead letter queue и резервного канала вроде SMS для критичных сообщений.

Как связать уведомления в приложении с событиями в 1С?

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

Сколько стоит доработать существующее приложение для устранения проблем с уведомлениями?

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

Что делать, если после исправления очереди уведомления всё равно теряются?

Нужно проверить логирование статусов доставки и наличие dead letter queue для недоставленных сообщений. Также стоит проверить, не конкурирует ли очередь уведомлений за ресурсы сервера с основными запросами приложения или 1С в моменты пиковой нагрузки.