Чому push-повідомлення торгового бота надходять із затримкою
Затримка push-повідомлень торгового бота майже ніколи не пов'язана з «повільним інтернетом». Повідомлення проходить ланцюжок: подія на біржовому шлюзі → черга повідомлень → сервіс розсилки → транспорт операційної системи → пристрій.
Розрив або затор на будь-якій ділянці дає одне й те саме: сигнал про угоду надходить, коли ціна вже пішла, а іноді не надходить узагалі.
Найчастіша причина — черга повідомлень. Якщо воркер розбирає її одним потоком, а потік подій у момент волатильності зростає в десятки разів, повідомлення накопичуються й доставляються пачкою із запізненням.
Друге джерело — фонова доставка: iOS та Android присипляють застосунок і ріжуть фонові з'єднання, тому постійний сокет не рятує, а агресивна економія заряду на пристрої може відкласти доставку на хвилини або заблокувати її до наступного відкриття застосунку.
Втрата повідомлень — окремий клас. Транспорт не гарантує доставку: якщо пристрій офлайн, а строк життя повідомлення вичерпано, воно зникає мовчки.
Плюс зміна токена при перевстановленні або оновленні — старий запис у базі підписок стає мертвим, і частина користувачів перестає отримувати сигнали, не підозрюючи про це.
Ми розбираємо цей ланцюжок за ділянками й закриваємо вузькі місця: пріоритетні канали для критичних подій, дедуплікація та підтвердження доставки, окремий шлях для алертів про угоди в обхід загальних розсилок. Далі — як це влаштовано і що дає на практиці.
Що дає відмовостійка доставка сигналів
Швидкість доставки сигналу перестає бути лотереєю: повідомлення надходить у момент спрацювання умови, а не при наступному відкритті застосунку. На практиці це різниця між входом за ціною та входом після руху — критичні секунди, які в торгівлі вирішують результат угоди.
Ми будуємо канал так, щоб затримка залишалася передбачуваною за будь-якого навантаження на ринку, включно з моментами різких сплесків волатильності, коли сервери бірж і оператори зв'язку працюють на межі.
Пропущені сигнали зникають як клас: кожне спрацювання отримує підтвердження доставки, а непідтверджені ставляться в чергу на повтор.
Якщо телефон у цей момент у зоні без мережі або застосунок вивантажено системою, повідомлення не губиться — воно дійде, щойно канал відновиться, і користувач побачить його з позначкою про час спрацювання.
Це принципово відрізняє торгового бота від звичайного месенджера, де втрачене повідомлення нікого не турбує.
Стійкість каналу забезпечується дублюванням маршрутів: основний канал, резервний і локальна перевірка на боці пристрою.
При обриві зв'язку система не мовчить і не накопичує сигнали до нескінченності — вона перемикається на альтернативний маршрут і продовжує доставку, а користувач бачить актуальний стан підключення.
Надійність повідомлень підтверджується метрикою частки доставлених сигналів: ми тримаємо її на рівні, за якого поодинокі збої не впливають на торгову логіку.
Передбачувана поведінка при обривах — окрема задача. Ми проєктуємо так, щоб при відновленні зв'язку користувач отримав не потік застарілих сигналів, а зведення з актуальними спрацюваннями та зрозумілою позначкою, які з них уже відпрацьовано.
Це знімає ризик хибних входів за «простроченими» повідомленнями і робить роботу з ботом спокійною навіть у нестабільній мережі.
Способи доставки: порівняння варіантів інтеграції
Способи доставки push-повідомлень торгового бота різняться не «швидкістю» як такою, а тим, де саме сигнал може застрягнути. Нижче — чотири реальні варіанти інтеграції, між якими обирають на старті, та їхні обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пряме надсилання через сервіс доставки (FCM/APNs) | Власний бекенд уже формує події угоди, потрібен контроль над текстом і таргетингом | Немає гарантії порядку доставки; за агресивного енергозбереження пристрою сигнал може надійти із затримкою; потрібна власна логіка повторів і дедуплікації |
| Через брокер повідомлень (черга + воркер-відправник) | Висока частота подій, кілька споживачів, потрібна стійкість до сплесків | З'являється проміжна ланка, яка сама потребує моніторингу; затримка зростає на час постановки та зняття з черги |
| Вебхук від біржі/брокера напряму в застосунок | Простий сценарій, мінімум інфраструктури | Немає гарантії доставки на пристрій, якщо застосунок закрито; легко губляться події за недоступності отримувача |
| Локальне опитування (періодичний запит стану) | Резервний канал, коли push недоступний | Затримка дорівнює інтервалу опитування; за частих запитів зростає витрата батареї та трафіку |
Ключове обмеження push як каналу — відсутність гарантії доставки на рівні операційної системи. Тому в продакшені зазвичай комбінують підходи: брокер тримає події, сервіс доставки надсилає їх, а локальне опитування працює як страховка на випадок, якщо сигнал не дійшов.
Вибір варіанта інтеграції визначається не «модністю» стеку, а вимогами до затримки та ціни втрати події.
Для торгового бота втрата одного повідомлення про угоду — це пропущений вхід або вихід, тому порівняння підходів варто вести за критерієм «що станеться, якщо сигнал не дійде», а не за середньою швидкістю доставки.
Як ми вибудовуємо доставку push-повідомлень торгового бота
Доставка push-повідомлень торгового бота — це не «підключити сервіс розсилок», а спроєктований маршрут: від події в ядрі торгівлі до екрана блокування телефона.
Нижче — як ми ведемо таку роботу, щоб повідомлення про спрацювання сигналу або виконання заявки надходило за секунди, а не губилося по дорозі.
- Аудит поточної схеми. Дивимося, де народжується подія, через які черги та сервіси вона йде, де стоїть фільтрація за типом сигналу і як влаштована авторизація пристрою. Фіксуємо вузькі місця: блокуючі виклики в обробнику події, відсутність розділення на критичні та інформаційні потоки, дублі при повторній доставці.
- Проєктування маршруту повідомлень. Розводимо потоки за класами: спрацювання сигналу, виконання заявки, зміна балансу, службові повідомлення. Для кожного класу визначаємо пріоритет, термін життя і поведінку при недоступності пристрою — критичні йдуть негайно, інформаційні збираються в дайджест.
- Налаштування доставки та пріоритетів. Налаштовуємо канали під обидві платформи, окремо — тихі години та групування, щоб серія сигналів не перетворювалася на шквал. Прописуємо правила повторного надсилання та підтвердження отримання, щоб повідомлення не губилося при обриві зв'язку.
- Перевірка сценаріїв. Проганяємо реальні торгові ситуації: різке зростання волатильності, серія сигналів підряд, пристрій у сплячому режимі, зміна мережі, відкликання доступу. Дивимося не «чи прийшло взагалі», а через скільки і в правильному чи порядку.
- Обробка відмов. Перевіряємо, що відбувається при недоставці: чи йде подія в резервну чергу, чи бачить користувач пропущене повідомлення в застосунку, чи не задвоюється доставка при повторній спробі.
- Узгодження порогів. Разом з вами визначаємо, які події критичні, а які можна агрегувати — від цього залежить, чи буде бот корисним інструментом або джерелом роздратування.
- Передача та спостереження. Віддаємо налаштовану схему, правила маршрутизації та метрики доставки: частка успішних, середній час, число повторів. Далі відстежуємо ці показники, щоб деградація була видна до скарг користувачів.
Опишіть вашу торгову логіку та поточну схему повідомлень — повернемося з оцінкою та планом робіт за етапами.
Конфігурації, схеми та регламенти на виході
Проєкт закривається не презентацією, а набором артефактів, за якими застосунок живе та розвивається без автора. Нижче — що саме залишається у вас у репозиторії та в системі моніторингу після здачі push-контуру торгового бота.
- Конфігурації каналів доставки: параметри підключення до сервісів сповіщень, розділення на транзакційні та маркетингові потоки, шаблони повідомлень зі змінними та правила їх валідації перед відправленням.
- Схеми маршрутизації: логіка вибору каналу під тип події (спрацьований ордер, зміна ціни, статус заявки), правила відкату на резервний канал у разі недоставки та таймаути повторних спроб.
- Політики пріоритетів: черговість обробки подій, обмеження частоти на користувача, вікна тиші та правила придушення дублів — щоб серія спрацьованих сигналів не перетворювалася на шквал.
- Регламенти експлуатації: порядок дій у разі деградації каналу, критерії перемикання на резерв, чек-ліст перевірки після інциденту та точки контролю метрик доставки.
- Документація з інтеграції: опис контрактів між торговим ядром і сервісом сповіщень, формати подій, вимоги до ідемпотентності та поведінка у разі повторної доставки.
- Дашборди та алерти: набір метрик за часом доставки, часткою успішних відправлень і відмовами за каналами, з порогами, за яких черговий отримує сигнал до того, як про проблему дізнаються користувачі.
- Інструкція з локального відтворення: як підняти тестовий контур, прогнати сценарії доставки та відмов, перевірити нові шаблони без ризику для бойового потоку.
Кожен артефакт версіонується разом із кодом, тому зміни в маршрутизації та пріоритетах проходять рев'ю та відкочуються так само, як звичайний реліз. Опишіть ваш сценарій — повернемося з оцінкою та планом, які з цих документів потрібні саме вам.
Кейс: як ми скоротили затримку сигналів у 4 рази
Клієнт — сервіс автоматичної торгівлі: сигнал генерується на стороні брокера, надходить до нашого бекенду і має дійти до трейдера раніше, ніж зміниться котирування. На старті сигнали формувалися на сервері, а мобільний застосунок забирав їх опитуванням за розкладом.
За активного ринку опитування не встигало за потоком подій: частина повідомлень надходила із затримкою, частина — вже неактуальною, і трейдер бачив вхід, коли ціна пішла.
Ми зняли метрики до змін: середня затримка доставки сигналу — близько 12 секунд, на пікових навантаженнях — до 40. Частка сигналів, доставлених пізніше 5 секунд, трималася на рівні 18%.
Окремо рахували частку втрачених повідомлень — система не розрізняла, чи дійшло повідомлення до пристрою, чи залишилося в черзі.
Firebase Cloud Messaging ми підключили як основний канал доставки, залишивши опитування лише як резервний сценарій. Сигнал тепер публікується в шину подій, звідти надходить до сервісу розсилки й доставляється пушем на пристрій.
Пріоритет повідомлення виставлено високий, щоб система не відкладала доставку за економії заряду, а на клієнті додано дедуплікацію — повторний пуш за тим самим сигналом не створює другий алерт.
Моніторинг перебудували навколо наскрізної трасування: кожен сигнал має ідентифікатор, за яким видно час генерації, постановки в чергу, відправлення та підтвердження отримання на пристрої. Це дало не лише цифри, а й розуміння, на якій ділянці губляться секунди.
| Метрика | До | Після |
|---|---|---|
| Середня затримка доставки | ~12 с | ~3 с |
| Затримка на піку | до 40 с | до 9 с |
| Частка сигналів пізніше 5 с | 18% | 4% |
| Втрачені повідомлення | не відстежувалися | <0,5% |
Затримку скоротили в 4 рази, а частка пізніх сигналів упала більш ніж учетверо. Трейдер отримує сигнал, поки він ще торгований, а команда бачить деградацію доставки за графіком, а не за скаргами.
Чим відрізняється push-повідомлення від in-app повідомлення?
Push-повідомлення надходить через системний сервіс операційної системи та спливає на заблокованому екрані, коли застосунок закрито або вивантажено з пам'яті.
In-app повідомлення живе всередині активної сесії: воно малюється поверх поточного екрана і існує лише поки користувач тримає застосунок відкритим.
Для торгового бота це два різних класи доставки — перший наздоганяє власника в будь-який момент, другий працює як уточнення до того, що вже відбувається на екрані.
Різниця проявляється в надійності та затримці. Системний канал не гарантує миттєву доставку: пристрій може бути в сплячому режимі, в зоні без мережі або під агресивною економією заряду, і тоді сигнал надходить із затримкою або згортається в один.
Всередині активної сесії повідомлення доставляється одразу по постійному з'єднанню, але тільки якщо застосунок на передньому плані.
Тому критичні події — спрацювання умови, виконання заявки, стоп-лосс — надсилаємо системним повідомленням, а деталі та підтвердження показуємо in-app, коли користувач уже в застосунку.
Вибір каналу — це не «або-або», а маршрутизація за станом клієнта. Сервер знає, чи активна сесія: якщо так, сигнал іде швидким шляхом і не дублюється банером; якщо ні — надходить системне повідомлення з високим пріоритетом.
Так користувач не отримує два повідомлення про одну подію і не пропускає важливе через те, що застосунок згорнуто.
Доповнюють одне одного вони і за змістом. Системне повідомлення несе мінімум: що спрацювало і на якому інструменті, — цього достатньо, щоб людина відкрила застосунок. Розгорнутий контекст — графік, обсяг, причина спрацювання — віддаємо in-app, де є місце і екран. Такий поділ знижує шум: короткий сигнал не перевантажений, а повна картина чекає всередині.
Окремо вирішуємо, що робити при недоставці. Якщо системний канал мовчить довше заданого порогу, бот повторює сигнал і позначає подію як непідтверджену — при наступному вході користувач бачить її в стрічці in-app.
Це страхує від втрати сигналу в момент, коли телефон був offline, і закриває головний ризик торгового бота: пропущене спрацювання.
Технічні сумніви та відповіді інженерів
Push-доставка в торговому боті ламається не на сервері, а на боці пристрою: агресивна економія заряду, слабкий зв'язок, кілька активних пристроїв і питання безпеки спливають уже на етапі експлуатації. Нижче — розбір частих технічних сумнівів, з якими до нас приходять команди після перших релізів.
Як поводяться сповіщення при слабкому зв'язку та обривах мережі?
Черга на клієнті зберігає події до відновлення каналу, а доставка йде з наростаючою паузою між спробами — пристрій не бомбардує сервер запитами і не втрачає сигнал при перемиканні між мережами.
Кожне сповіщення отримує ідентифікатор, тому повторне надсилання не створює дублів: клієнт відкидає вже показані події. При поверненні зв'язку приходить не весь накопичений потік, а актуальний стан — за ордером видно поточний статус, а не застарілий ланцюжок.
Чому система економії заряду «вбиває» сповіщення і як це обходиться?
Обмеження фонової роботи відтинають частину каналів доставки, тому ми не покладаємося на один шлях. Критичні події йдуть через службовий канал, який система не згортає, а звичайні — через штатний.
Для торгових сигналів це означає: спрацювання за ціною або стопом приходить навіть при жорсткій економії, а інформаційні зведення можуть зачекати. Налаштування енергозбереження на конкретних моделях ми перевіряємо окремо — це частина приймання, а не сюрприз після запуску.
Що відбувається, якщо користувач увійшов з кількох пристроїв?
Кожен пристрій реєструється як окремий отримувач зі своїм ключем, а прив'язка йде до акаунта, а не до телефону. Користувач бачить список активних пристроїв і може відкликати будь-який — токен відкликається на сервері, і доставка на нього припиняється одразу.
Якщо спрацював торговий сигнал, сповіщення йде на всі активні пристрої, але дія за ним фіксується один раз: повторне підтвердження з іншого телефону не створює другої угоди.
Наскільки безпечна передача торгових даних у сповіщеннях?
У тексті сповіщення немає чутливих даних — лише ідентифікатор події та короткий статус, решту клієнт запитує захищеним каналом після автентифікації. Токени пристроїв зберігаються в захищеному сховищі та відкликаються при виході з акаунта або зміні пароля.
Це закриває основний ризик: перехоплене сповіщення не дає доступу до рахунку і не розкриває позиції.
Якщо у вас залишилися сумніви щодо конкретного сценарію — опишіть задачу, повернемося з оцінкою та планом.
Обговоримо ваше завдання і повернемося з планом
Щоб повернутися з оцінкою, а не із загальними словами, нам потрібно зрозуміти вашу поточну схему доставки сповіщень.
Опишіть, як сигнал від торгового бота зараз потрапляє на пристрій: через власний сервер, сторонній сервіс чи напряму з бекенду біржі, і що відбувається під час сплеску ринкової активності. Цього достатньо, щоб запропонувати рішення та план робіт.
Що корисно додати до опису завдання:
- поточний шлях сигналу: від генерації до екрана телефона, із зазначенням усіх проміжних ланок;
- як обробляються сплески: що відбувається при різкому зростанні кількості угод і одночасних оповіщень;
- поведінка на iOS та Android: чи є розбіжності за затримкою та доставкою у фоновому режимі;
- що вже пробували: черги, пріоритети, групування, обмеження частоти;
- вимоги до надійності: чи критично отримати сигнал при слабкій мережі та після перезапуску застосунку;
- доступи та обмеження: які сервіси вже використовуються і чи є прив'язка до конкретного постачальника;
- терміни та очікування щодо навантаження: скільки користувачів і сигналів у піку ви закладаєте.
Далі ми розберемо вузькі місця, запропонуємо архітектуру доставки та повернемося з оцінкою за етапами: що робимо першим, що можна відкласти, де потрібна міграція.
Наступний крок — коротка розмова за вашою схемою, після якої ви отримаєте план робіт із пріоритетами та зрозумілими термінами. Обговоримо завдання — опишіть поточний устрій у двох абзацах, і ми повернемося з рішенням.
