Розробка підписки на торгові сигнали: real-time доставка без затримок
Торгові сигнали потребують мінімальної затримки. Користувач заплатив за підписку на торгові сигнали, але отримав push-сповіщення через 40 секунд після генерації сигналу — на той момент ціна вже пішла. Різниця між 500 мс і 40 секундами вирішує результат угоди. WebSocket у 100 разів швидше ніж push при активному застосунку, але потребує грамотної архітектури. Ми проектуємо канали так, щоб затримка не перевищувала 500 мс в активному режимі та 5 хвилин у фоні (push fallback). Економія на push-інфраструктурі за рахунок пріоритизації WebSocket сягає 30%. Ми маємо 10+ років досвіду в мобільній розробці та понад 50 випущених застосунків — це гарантує надійність рішення.
Як підписка на торгові сигнали через WebSocket забезпечує доставку за 100–500 мс?
FCM та APNS для доставки сигналів — ненадійне рішення поодинці. Apple та Google не гарантують latency push-сповіщень: у періоди навантаження затримка може сягати 1–5 хвилин. Правильна схема — два канали паралельно:
- WebSocket (primary). Поки застосунок активний (foreground) — підключений до сервера через WebSocket (
URLSessionWebSocketTaskна iOS,OkHttp WebSocketна Android). Сигнал приходить протягом 100–500 мс від генерації. При втраті з'єднання — exponential backoff reconnect (1s → 2s → 4s → 8s → max 30s). - Push (fallback). Коли застосунок у background або closed — FCM/APNS Data Message (silent push на iOS) будить застосунок через
BGProcessingTaskабоUNNotificationServiceExtension.NSEзапускається на кожен push і може показати сповіщення з розшифрованим вмістом — туди додаємо тікер, напрямок (BUY/SELL), ціну входу.
| Канал | Затримка (активний режим) | Затримка (background) | Надійність |
|---|---|---|---|
| WebSocket | 100–500 мс | — | Висока |
| Push FCM/APNS | — | 1–5 хвилин | Середня |
Важливий нюанс iOS: UNNotificationServiceExtension має близько 30 секунд на обробку. Якщо за цей час не викликано contentHandler — система показує оригінальний push. NSE не повинен робити важкі мережеві запити.
Як реалізувати платну підписку на торгові сигнали з grace period?
Модель: платний доступ через Auto-Renewable Subscription з використанням StoreKit 2 на iOS та Play Billing Library 6+ на Android. Користувач без активної підписки бачить сигнали із затримкою (демо-режим) або не бачить взагалі.
Валідація entitlement на сервері через App Store Server Notifications V2 (APNS-підписані JWT події від Apple) та Google Play Real-time Developer Notifications (Pub/Sub). Не покладаємося на клієнтську валідацію — сервер WebSocket при встановленні з'єднання перевіряє subscription_status із власної БД, що оновлюється за серверними webhook'ами від сторів.
Grace period: якщо підписка не продовжилася через біллінг — не рубаємо доступ миттєво. StoreKit 2 Transaction.currentEntitlements повертає транзакцію зі статусом inGracePeriod — показуємо банер «Проблема з оплатою, оновіть картку» та даємо 3–6 днів. Це знижує involuntary churn. Наприклад, зниження involuntary churn на 15% економить до $8 000 щомісячного доходу для застосунку з 10 000 підписників.
| Платформа | Бібліотека | Серверна валідація | Grace period |
|---|---|---|---|
| iOS | StoreKit 2, Transaction.currentEntitlements | App Store Server Notifications V2 | inGracePeriod |
| Android | Play Billing Library 6+, BillingClient.queryPurchasesAsync | Google Play Real-time Developer Notifications | accountHold |
Чому для підписки на торгові сигнали потрібна серверна валідація entitlement?
Клієнтська перевірка підписки може бути обійдена. На сервері ми агрегуємо події від сторів і зберігаємо актуальний статус. WebSocket-з'єднання авторизується токеном, який перевіряється проти БД. Це захищає від джейлбрейк-обходів та підробки відповідей. Додатково знижується навантаження на підтримку — менше суперечок про списання.
Що входить в роботу
- Архітектурна документація — схема підписок, вибір тарифів, опис grace period та trial.
- Розробка WebSocket-сервера — реалізація каналу доставки з exponential backoff.
- Інтеграція push-каналу — FCM/APNS з NSE для iOS та обробка фонових сповіщень.
- Реалізація StoreKit 2 / Play Billing — on-device покупки, серверна валідація, webhook-інтеграція.
- UI стрічки сигналів — real-time оновлення через DiffableDataSource / Paging 3.
- Тестування — вимірювання затримки, stress-тести WebSocket при 10k+ одночасно підключених.
- Деплой та моніторинг — налаштування сповіщень про збої, дашборд latency.
- Підтримка після публікації — 30 днів на баг-фікси та консультації.
Процес роботи
- Проектування схеми підписок (тарифні плани, trial, grace period)
- Розробка WebSocket-сервера та інтеграція push-каналу
- Реалізація StoreKit 2 / Play Billing підписки з серверною валідацією
- Розробка UI стрічки сигналів з real-time оновленнями
- Тестування затримки доставки та моніторинг
- Документація API та схеми роботи
- Підтримка після публікації
Орієнтири за термінами
Реалізація підписки + WebSocket стрічка сигналів + push fallback — 3–5 робочих днів при готовому API. Якщо включає проектування серверної частини (WebSocket сервер, Pub/Sub інтеграція зі стором) — 2–3 тижні.
Що робить нашу реалізацію надійною?
Ми спеціалізуємося на мобільній розробці 10+ років, опублікували понад 50 застосунків в App Store та Google Play. Глибоке розуміння in-app purchase та real-time комунікацій дозволяє мінімізувати затримки та задовольняти вимогам App Store Review Guidelines. Замовте впровадження — ваш користувач не пропустить жодного сигналу. Отримайте консультацію з підписної моделі.