Реалізація уведомлень про крупні транзакції в мобільному додатку
Крупна транзакція на $50 млн пройшла в мережі — користувач дізнався про це через 40 хвилин, уже після того як ринок відреагував. Така затримка робить трекер марним. Whale Alert — це завдання реального часу, де похибка в хвилину критична, а архітектура сповіщень впливає на цінність всього продукту.
Джерела даних та чому це складніше, ніж здається
Більшість команд починають з публічного 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 в USD-еквіваленті) воркер формує payload та надсилає через FCM (Android) та APNs (iOS) одночасно
- Клієнт отримує сповіщення у фоні, відображає його через
UNUserNotificationCenter(iOS) абоNotificationCompat.Builder(Android)
На iOS важливо правильно налаштувати apns-priority: 10 для срочних сповіщень — інакше APNs може буферизувати доставку до наступного пробудження пристрою. Для цього потрібен entitlement com.apple.developer.usernotifications.time-sensitive.
Фільтрація та персоналізація на стороні клієнта
Користувач не хочу отримувати сповіщення про кожну транзакцію на $500K — він налаштовує пороги. Типовий набір фільтрів:
- Мінімальна сума транзакції (в USD або нативній монеті)
- Напрямок: лише входячі на біржу, лише вихідні з біржи, peer-to-peer
- Мережі: BTC, ETH, SOL, TRX та ін.
- Адреси з watchlist
Ці налаштування зберігаються на сервері та прив'язані до FCM-топіку або індивідуального токена. Перший варіант простіший для рассилки, другий — гнучкіший для персоналізації. На практиці використовуємо гібридну схему: топіки для загальних пороговых подій (whale_btc_1m) та індивідуальні токени для watchlist-адрес.
На стороні додатка фільтри реалізуємо через UNNotificationServiceExtension (iOS) — розширення перехоплює сповіщення до показу та може його відхилити або модифікувати на основі локальних налаштувань. На Android аналогічно через FirebaseMessagingService.onMessageReceived() з ручним викликом або пропуском NotificationManager.
Технічна реалізація
Стек сервера: Node.js воркер + Redis Pub/Sub для розподілу завдань між кількома інстансами + Firebase Admin SDK для надсилання.
Для iOS використовуємо APNs через HTTP/2 напрямки (бібліотека node-apn або @parse/node-apn) — це швидше, ніж через FCM-прокси. Різниця в затримці невелика, але при високій навантаженості (>10K пристроїв) прямий APNs стабільніший.
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).
Моніторинг доставки
Firebase Console показує лише базову статистику. Для production важливо трекати:
- Delivery rate — відсоток успішно доставлених сповіщень (FCM Analytics)
- Time-to-deliver — час від виявлення подієї до отримання на пристрої
- Open rate — скільки користувачів тапнули
Для time-to-deliver використовуємо власну метрику: сервер пише timestamp надсилання в payload, клієнт логує timestamp отримання та надсилає дельту в аналітику (Mixpanel або власний ClickHouse).
Етапи роботи
- Аудит джерел даних — вибір API, оцінка затримки та надійності стримів
- Архітектура серверного воркера — polling/WebSocket, обробка дублів, rate limiting
- Налаштування FCM + APNs, отримання сертифікатів/ключів
- Реалізація клієнтської частини — запит дозволів, обробка токенів, deep linking
- Система фільтрів користувача — UI налаштувань, синхронізація з сервером
- Тестування на реальних пристроях (Doze Mode, Background App Refresh)
- Моніторинг та alerting
Сроки: від 2 тижнів для базової інтеграції (готовий бекенд + один стрім) до 5–6 тижнів при розробці з нуля з кастомними фільтрами та підтримкою 5+ блокчейнів.