Чому сповіщення NFT у застосунку надходять із запізненням
Затримка push-сповіщення про торги NFT майже ніколи не народжується в самому push-сервісі. Вона накопичується ланцюжком: застосунок або бекенд опитує блокчейн, чекає підтвердження транзакції, зіставляє подію з підписками користувача — і лише потім надсилає сповіщення.
Кожна ділянка додає свої секунди, а на торгах, де ставку перебивають за хвилини, цього достатньо, щоб користувач дізнався про подію, коли вона вже неактуальна.
Перше джерело затримки — опитування блокчейну. Якщо застосунок звертається до мережі за розкладом, між двома перевірками минає фіксований інтервал, і подія, що потрапила в нього, чекає наступного циклу.
Чим рідше опитування, тим вища ймовірність пропустити момент, коли торги ще можна виграти. У частини рішень перевірка взагалі запускається лише за відкритого застосунку — у фоні сповіщення NFT не надходять зовсім.
Друге джерело — момент фіксації події. Транзакція спершу потрапляє в мемпул і лише потім підтверджується. Якщо сповіщення будується на непідтвердженій події, воно може прийти, а потім відкотитися разом із реорганізацією ланцюга.
Якщо чекати на фінальність — затримка push зростає, і пропуск торгів стає ймовірнішим. Тут потрібен компроміс: раннє сповіщення про появу ставки й окреме — про підтвердження.
Третя ділянка — доставка сповіщень на пристрій. Мобільні платформи обмежують фонову роботу: система може призупинити застосунок, відкласти мережевий запит або згрупувати кілька сповіщень в одне.
Окрема проблема — зіставлення події з підписками: якщо користувач стежить за десятком колекцій, а фільтр будується на боці пристрою, частина подій відсіюється ще до надсилання.
Ми розбираємо цей ланцюжок за ланками й знаходимо, де саме втрачається час: у розкладі опитування, у логіці підтверджень чи в правилах доставки. Далі — як це закривається.
Що дає налагоджений канал сповіщень про торги
Швидкість доставки сповіщень про торги NFT визначається не швидкістю надсилання, а тим, як застосунок отримує їх у фоні. Якщо покладатися лише на періодичне опитування сервера, подія «ставку перебито» доходить до власника із затримкою в хвилини — за цей час торги вже закрито.
Постійне з'єднання із сервером плюс системний канал доставки скорочують цей розрив до секунд, і рішення щодо ставки ухвалюється, поки лот ще активний.
Частка успішних показів залежить від двох речей: пріоритету сповіщення та стану самого застосунку. Якщо канал один на всі події, важлива ставка губиться серед службових повідомлень і рекламних нагадувань.
Розділення на окремі категорії з різними пріоритетами та звуками підвищує частку показів, а групування дубльованих подій за лотом прибирає візуальний шум — користувач бачить одне сповіщення замість п'яти.
Пропущені події майже завжди спричинені одним: застосунок вивантажено з пам'яті або сповіщення вимкнено на рівні системи.
Тут працює зв'язка — збереження події на сервері та досилання під час наступного запуску, плюс м'який запит дозволів у момент, коли користувач уперше зробив ставку, а не на першому екрані. Це знижує кількість втрачених торгів без тиску на користувача.
Навантаження на застосунок при цьому не зростає: фонові завдання виконуються системним механізмом, а не постійним циклом усередині процесу.
Застосунок не тримає зайвих з'єднань і не витрачає заряд у фоні — сповіщення надходять, навіть коли його закрито, а під час відкриття підтягується лише актуальний стан лота.
Підходи до відстеження подій торгів та їх обмеження
Події торгів можна отримувати трьома способами: періодичним опитуванням, потоковою підпискою та гібридною схемою. Різниця проявляється не в «правильності», а в тому, які вимоги до затримки, вартості та стійкості ви ставите. Нижче — як це влаштовано на практиці та де кожен варіант ламається.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Періодичне опитування | Рідкісні торги, нечутливість до затримки в десятки секунд | Затримка зростає з інтервалом; при частих запитах зростає навантаження та ризик відсікання за лімітами |
| Потокова підписка | Активні торги, потрібна реакція за секунди | Потребує перепідключення та доганяння пропущеного вікна при обриві зв'язку |
| Гібридна схема | Змішана активність: підписка на гарячі лоти, опитування для решти | Складніша в супроводі: два джерела потрібно зводити без дублів |
Як вибирається схема
Ключовий параметр — скільки подій торгів надходить за одиницю часу і наскільки критична затримка. Якщо лот перебивають раз на хвилину, опитування раз на 10–15 секунд дає прийнятну свіжість і не потребує постійного з'єднання.
Якщо ставки йдуть потоком, підписка виграє: подія доходить майже одразу, а не після наступного циклу.
Де ламаються крайні варіанти
Чиста підписка вразлива до розривів: при втраті з'єднання частина подій губиться, і без механізму доганяння користувач бачить застарілий стан. Чисте опитування впирається в ліміти і не масштабується на багато активних лотів.
Гібридна схема закриває обидва випадки, але потребує дедуплікації — одна подія може надійти і з підписки, і з опитування.
Розбираємо, як це закривається в застосунку: вибір схеми під профіль торгів, перепідключення з доганянням пропущеного вікна та доставка повідомлень NFT без дублів.
Як ми вибудовуємо доставку сповіщень NFT
Сповіщення про торги — це не один виклик push-сервісу, а маршрут події від блокчейну до екрана телефона. Ставка висока: пропущений сигнал про ставку на лот означає програний аукціон.
Тому ми проєктуємо доставку як окрему підсистему з ідемпотентністю, повторами та спостережуваністю, а не як функцію «надіслати пуш».
- Аудит подій і сценаріїв. Розбираємо, які події взагалі породжують сповіщення: нова ставка, перебита ставка, закінчення лота, виграш, скасування. Для кожної фіксуємо пріоритет, термін актуальності та те, що робити, якщо подія застаріла на момент відправлення.
- Схема маршрутизації. Будуємо правила: кому, яким каналом і з якою затримкою йде подія. Враховуємо підписки користувача, тихі години, частотні ліміти та об'єднання кількох ставок за одним лотом в одне повідомлення, щоб не завалювати людину десятком сигналів.
- Налаштування каналів доставки. Push як основний канал, усередині застосунку — стрічка подій, електронна пошта — для критичних статусів на кшталт виграшу. Для кожного каналу задаємо пріоритет, поведінку при відмові та правила перемикання на резервний.
- Налаштування push. Реєструємо пристрої, зберігаємо токени з прив'язкою до акаунта, обробляємо їхню ротацію та відкликання при виході з профілю. Окремо налаштовуємо групи сповіщень і звук, щоб сигнал про ставку відрізнявся від службових повідомлень.
- Перевірка доставки. Проганяємо сценарії на стенді: доставка при активному застосунку, у фоні та після перезапуску, поведінка при недоступному каналі, коректність повторів і відсутність дублів. Дивимося частку успішних доставок і час від події до показу.
- Спостережуваність. Логуємо шлях кожного сповіщення — від появи події до відкриття користувачем. Це дозволяє розбирати скарги «не прийшло» за фактом, а не за здогадкою.
- Передача та регламент. Віддаємо схему маршрутизації, конфігурацію каналів, дашборд доставки та інструкцію з додавання нових типів подій без перезбирання логіки.
Такий порядок прибирає головний ризик — тиху втрату сповіщень, коли ставка пройшла, а користувач про неї не дізнався.
Що замовник отримує після впровадження
Після впровадження сповіщень про торги 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 і за яких умов має отримувати користувач.
- Обмеження за строками та те, що вже зроблено із цього завдання.
Опишіть завдання у вільній формі — повернемося з оцінкою, планом робіт за етапами та пропозицією щодо старту проєкту. Якщо частина вхідних даних поки не готова, розберемо її разом на дзвінку та зафіксуємо припущення в плані.
