Реализация уведомлений о торгах NFT в мобильном приложении

Почему уведомления NFT в приложении приходят с опозданием

Задержка push-уведомления о торгах NFT почти никогда не рождается в самом push-сервисе. Она накапливается по цепочке: приложение или бэкенд опрашивает блокчейн, ждёт подтверждения транзакции, сопоставляет событие с подписками пользователя — и только потом отправляет уведомление. Каждый участок добавляет свои секунды, а на торгах, где ставку перебивают за минуты, этого достаточно, чтобы пользователь узнал о событии, когда оно уже неактуально.

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

Второй источник — момент фиксации события. Транзакция сначала попадает в мемпул и лишь затем подтверждается. Если уведомление строится на неподтверждённом событии, оно может прийти, а затем откатиться вместе с реорганизацией цепи. Если ждать финальности — задержка push растёт, и пропуск торгов становится вероятнее. Здесь нужен компромисс: раннее уведомление о появлении ставки и отдельное — о подтверждении.

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

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

Что даёт отлаженный канал уведомлений о торгах

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

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

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

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

Подходы к отслеживанию событий торгов и их ограничения

События торгов можно получать тремя способами: периодическим опросом, потоковой подпиской и гибридной схемой. Разница проявляется не в «правильности», а в том, какие требования к задержке, стоимости и устойчивости вы ставите. Ниже — как это устроено на практике и где каждый вариант ломается.

Как выбирается схема

Ключевой параметр — сколько событий торгов приходит в единицу времени и насколько критична задержка. Если лот перебивают раз в минуту, опрос раз в 10–15 секунд даёт приемлемую свежесть и не требует постоянного соединения. Если ставки идут потоком, подписка выигрывает: событие доходит почти сразу, а не после следующего цикла.

Где ломаются крайние варианты

Чистая подписка уязвима к разрывам: при потере соединения часть событий теряется, и без механизма догона пользователь видит устаревшее состояние. Чистый опрос упирается в лимиты и не масштабируется на много активных лотов. Гибридная схема закрывает оба случая, но требует дедупликации — одно событие может прийти и из подписки, и из опроса.

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

Как мы выстраиваем доставку уведомлений NFT

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

1. Аудит событий и сценариев. Разбираем, какие события вообще порождают уведомление: новая ставка, перебитая ставка, окончание лота, выигрыш, отмена. Для каждого фиксируем приоритет, срок актуальности и то, что делать, если событие устарело к моменту отправки.
2. Схема маршрутизации. Строим правила: кому, по какому каналу и с какой задержкой уходит событие. Учитываем подписки пользователя, тихие часы, частотные лимиты и объединение нескольких ставок по одному лоту в одно сообщение, чтобы не заваливать человека десятком сигналов.
3. Настройка каналов доставки. Push как основной канал, внутри приложения — лента событий, электронная почта — для критичных статусов вроде выигрыша. Для каждого канала задаём приоритет, поведение при отказе и правила переключения на резервный.
4. Настройка push. Регистрируем устройства, храним токены с привязкой к аккаунту, обрабатываем их ротацию и отзыв при выходе из профиля. Отдельно настраиваем группы уведомлений и звук, чтобы сигнал о ставке отличался от служебных сообщений.
5. Проверка доставки. Прогоняем сценарии на стенде: доставка при активном приложении, в фоне и после перезапуска, поведение при недоступном канале, корректность повторов и отсутствие дублей. Смотрим долю успешных доставок и время от события до показа.
6. Наблюдаемость. Логируем путь каждого уведомления — от появления события до открытия пользователем. Это позволяет разбирать жалобы «не пришло» по факту, а не по догадке.
7. Передача и регламент. Отдаём схему маршрутизации, конфигурацию каналов, дашборд доставки и инструкцию по добавлению новых типов событий без пересборки логики.

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

Что заказчик получает после внедрения

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

• Конфигурации сервиса уведомлений — правила подписки на события торгов, шаблоны сообщений по типам (ставка перебита, лот выигран, торги завершены), настройки группировки, чтобы пользователь не получал лавину пушей при активном лоте.
• Схемы потоков — от события на площадке до доставки на устройство: где формируется уведомление, где отсекаются дубли, где хранится очередь и что происходит при недоступности получателя.
• Политики доступа — разграничение прав на отправку, редактирование шаблонов и просмотр статистики доставки; отдельно — правила хранения токенов устройств и персональных данных подписчиков.
• Документация по интеграции — описание событий и форматов, которые приложение принимает и отдаёт, с примерами запросов и ответов для команды, которая будет подключать новые типы торгов.
• Регламенты эксплуатации — порядок действий при сбое доставки, при жалобах на частоту уведомлений, при плановых работах на стороне площадки.
• Дашборд доставки — метрики по отправленным, доставленным и открытым уведомлениям в разрезе типов событий, чтобы видеть деградацию до того, как её заметят пользователи.
• Инструкция по откату — как вернуть предыдущую конфигурацию рассылки и какие проверки прогнать после отката.

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

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

Клиент — маркетплейс цифровых активов на базе OpenSea-совместимых контрактов — жаловался, что ставки на аукционах «протухают»: пользователь узнавал о перебитой ставке через минуты, когда торги уже закрылись. Метрики до работ: медиана доставки уведомления о новом биде — 40 секунд, доля успешных показов — 71%, пропуски событий при пиковой нагрузке (массовый дроп коллекции) — до 9% от общего числа ставок.

Что было не так

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

Что изменили

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

Результат

Медиана доставки — 3 секунды вместо 40, доля успешных показов выросла с 71% до 98,6%, пропуски событий на пике — 0,2% против 9%. Отдельно замерили метрику «успел перебить ставку»: доля пользователей, отреагировавших до закрытия лота, выросла втрое — это уже про деньги клиента, а не про инфраструктуру.

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

Чем отличается потоковая подписка от периодического опроса?

Периодический опрос — это цикл, в котором приложение само раз в N секунд спрашивает сервер, не появилось ли новых лотов. Задержка между реальным событием и уведомлением равна половине интервала в среднем и полному интервалу в худшем случае: при опросе раз в 30 секунд ставка на редкий лот уходит конкуренту, который увидел его на 25 секунд раньше. Уменьшать интервал — значит линейно растить нагрузку: каждый активный пользователь превращается в поток запросов, большая часть которых возвращает пустой ответ.

Потоковая подписка переворачивает модель: клиент один раз открывает долгоживущее соединение, а сервер сам проталкивает событие в момент его появления. Задержка падает до времени доставки одного сообщения — доли секунды вместо десятков секунд, и она не зависит от числа подписок. Нагрузка при этом пропорциональна числу реальных событий, а не числу пользователей, умноженному на частоту опроса: сервер не тратит ресурсы на проверки «в пустоту».

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

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

Частые технические сомнения

Уведомления о торгах — это не «пуш по событию», а конвейер с гарантией доставки. Ниже — то, что чаще всего уточняют инженеры заказчика перед стартом.

Что будет при росте нагрузки в момент пиковых торгов?

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

Как это встроится в нашу существующую инфраструктуру?

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

Можно ли откатить или отключить отдельные типы уведомлений?

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

Обсудим вашу задачу по уведомлениям

Чтобы вернуться с оценкой и планом работ, а не с общими словами, нам нужен минимум вводных по вашему продукту. Уведомления NFT — это не одна функция, а связка: источник событий (маркетплейс, аукцион, блокчейн-события), правила фильтрации под конкретного пользователя и канал доставки на устройство. Чем точнее вы опишете текущий ландшафт, тем быстрее мы перейдём от обсуждения задачи к конкретному плану.

Что разберём на первом созвоне

• Источники событий. Откуда приходят данные о торгах: собственный бэкенд, внешние маркетплейсы, прямые события из сети. Это определяет, нужен ли отдельный слой агрегации и как часто опрашивать источники.
• Правила подписки. По каким коллекциям, лотам и порогам пользователь хочет получать уведомления NFT — и где эти правила хранятся: на клиенте, на сервере или в обоих местах.
• Каналы доставки. Push через системные сервисы, внутриприложенческие сообщения, резервные каналы на случай, когда push не дошёл. Разбираем, что критично для вашего сценария.
• Текущая архитектура. Что уже есть в приложении: авторизация, профиль пользователя, работа с блокчейном. Это покажет, что переиспользуем, а что придётся строить.
• Нагрузка и поведение. Сколько пользователей, сколько событий в пике, как часто меняются лоты. От этого зависит схема очередей и дедупликации.
• Платформы и ограничения. iOS и Android по-разному работают с фоновыми уведомлениями и разрешениями — учитываем это в плане, а не после запуска.
• Критерии готовности. Что для вас значит «работает»: задержка доставки, доля доставленных, отсутствие дублей. Зафиксируем это до старта проекта.

Что прислать до созвона

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

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