Мобильное приложение 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+ блокчейнов. Закажите консультацию — мы оценим ваш проект и предложим оптимальное решение.