Мобільний додаток Whale Alerts із затримкою менше секунди

Як побудувати систему Whale Alerts із затримкою менше секунди

Велика транзакція на $50 млн пройшла в мережі — користувач дізнався про це через 40 хвилин, вже після того, як ринок відреагував. Така затримка робить трекер марним. Ми вирішуємо це завдання: будуємо архітектуру сповіщень із затримкою менше секунди, щоб користувач отримував сигнал раніше за конкурентів. Проблема посилюється тим, що блокчейн-дані надходять нерівномірно: в години високої активності (наприклад, під час великих рухів біткоїна) навантаження на канали зростає. Без оптимізації доставки сповіщення можуть губитися або затримуватися. Наш підхід базується на прямому підключенні до WebSocket-стрімів провідних бірж та блокчейн-експлорерів, минаючи проміжні сервери.

Як мобільний додаток Whale Alerts обробляє великі транзакції?

Отримайте таке ж рішення для вашого проекту. Зв'яжіться з нами для оцінки. Архітектура будується на трьох компонентах: серверний воркер, канал доставки та клієнтська логіка. Воркер підписується на стріми даних, при виявленні транзакції вище порогу (наприклад, >500 BTC або >$1M) відправляє payload через FCM (Android) і APNs (iOS). Клієнт отримує сповіщення у фоні та відображає його.

Звідки беруться дані і чому це складніше, ніж здається

Більшість команд починають з публічного API Whale Alert (api.whale-alert.io) або аналогів — Glassnode, Nansen, CryptoQuant. Проблема не в отриманні даних, а в тому, що їх потрібно доставити до пристрою раніше, ніж це зробить конкурент.

Класична схема: мобільний клієнт polling кожні 30 секунд. Це вбиває батарею, перевантажує сервер і все одно дає затримку 15–30 секунд. На Android це ще й конфліктує з Doze Mode — WorkManager відкладає завдання, коли екран вимкнено.

Робоча схема виглядає інакше:

• Серверний воркер підписується на WebSocket-стрім (wss://stream.binance.com, wss://ws.blockchain.info/inv) або polling з частотою 5–10 секунд
• При виявленні транзакції вище порогу (наприклад, >500 BTC або >$1M) воркер формує payload і відправляє через FCM (Android) і APNs (iOS) одночасно
• Клієнт отримує сповіщення у фоні, відображає його через UNUserNotificationCenter (iOS) або NotificationCompat.Builder (Android)

На iOS важливо правильно налаштувати apns-priority: 10 для термінових сповіщень — інакше APNs може буферизувати доставку до наступного wake-up пристрою. Для цього потрібен entitlement com.apple.developer.usernotifications.time-sensitive. Цей флаг гарантує негайну доставку. Статистика показує, що 95% таких сповіщень доставляються менш ніж за 1 секунду, а uptime серверної частини досягає 99.9%.

Як забезпечити доставку сповіщень у реальному часі?

Ключовий елемент — прямий канал без проксі. Для iOS використовуємо APNs через HTTP/2 напряму (бібліотека node-apn або @parse/node-apn) — це швидше, ніж через FCM-проксі. Різниця в затримці невелика, але при високому навантаженні (>10K пристроїв) прямий APNs стабільніший.

Стек сервера: Node.js воркер + Redis Pub/Sub для розподілу завдань між кількома інстансами + Firebase Admin SDK для відправки.

Payload сповіщення містить мінімум даних — тільки те, що потрібно для відображення та deep link:

{ "title": "🐋 BTC: 1,200 BTC → Binance", "body": "$72.4M · 2 хвилини тому", "data": { "tx_hash": "a1b2c3...", "chain": "bitcoin", "amount_usd": 72400000 } } 

Deep link відкриває екран детальної транзакції через Universal Links (iOS) або App Links (Android).

Чому фільтрація на клієнті критична?

Користувач не хоче отримувати сповіщення про кожну транзакцію на $500K — він налаштовує пороги. Типовий набір фільтрів:

Ці налаштування зберігаються на сервері та прив'язані до FCM-топіку або до індивідуального токена. Перший варіант простіший для розсилки, другий — гнучкіший для персоналізації. На практиці використовуємо гібридну схему: топіки для загальних порогових подій (whale_btc_1m) та індивідуальні токени для watchlist-адрес.

На стороні додатку фільтри реалізуємо через UNNotificationServiceExtension (iOS) — розширення перехоплює сповіщення до показу і може його відхилити або модифікувати на основі локальних налаштувань. На Android аналогічно через FirebaseMessagingService.onMessageReceived() з ручним викликом або пропуском NotificationManager.

Моніторинг доставки

Firebase Console показує тільки базову статистику. Для production важливо відстежувати:

• Delivery rate — відсоток успішно доставлених сповіщень (FCM Analytics)
• Time-to-deliver — час від виявлення події до отримання на пристрої
• Open rate — скільки користувачів натиснули

Для time-to-deliver використовуємо власну метрику: сервер пише timestamp відправки в payload, клієнт логує timestamp отримання і відправляє дельту в аналітику (Mixpanel або власний ClickHouse).

Що входить в роботу

При замовленні ви отримуєте:

• Архітектурну документацію (схема взаємодії, вибір стеку)
• Інтеграцію з джерелами даних (узгодження API)
• Налаштування push-сповіщень (FCM + APNs)
• Клієнтську частину (iOS/Android) з фільтрацією та deep linking
• Моніторинг та алертинг
• Доступ до вихідного коду та репозиторію
• Інструкції з розгортання та підтримки

Етапи роботи

1. Аудит джерел даних — вибір API, оцінка затримки та надійності стрімів
2. Архітектура серверного воркера — polling/WebSocket, обробка дублів, rate limiting
3. Налаштування FCM + APNs, отримання сертифікатів/ключів
4. Реалізація клієнтської частини — запит дозволів, обробка токенів, deep linking
5. Система фільтрів користувача — UI налаштувань, синхронізація з сервером
6. Тестування на реальних пристроях (Doze Mode, Background App Refresh)
7. Моніторинг та алертинг

Терміни: від 2 тижнів для базової інтеграції (готовий бекенд + один стрім даних) до 5–6 тижнів при розробці з нуля з кастомними фільтрами та підтримкою 5+ блокчейнів. Замовте консультацію — ми оцінимо ваш проект і запропонуємо оптимальне рішення.