Реализация уведомлений о крупных транзакциях (Whale Alerts) в мобильном приложении

Реализация уведомлений о крупных транзакциях (Whale Alerts) в мобильном приложении

Крупная транзакция на $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 может буферизировать доставку до следующего wake-up устройства. Для этого нужен 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).

Этапы работы

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+ блокчейнов.