Розробка системи сповіщень для трейдерів під ключ

Трейдер, який пропустив маржин-колл, втрачає депозит. Алерт, що прийшов на 2 секунди пізніше, робить стратегію марною. Уявіть: ви тримаєте позицію на 100 ETH, і раптово ринок летить вниз. Ваш stop-loss спрацював, але сповіщення прийшло лише через хвилину — вже пізно. Стандартні рішення для масових розсилок не підходять: email-провайдери не гарантують latency, push-провайдери можуть батчити повідомлення. Ми будуємо кастомну архітектуру, де кожне критичне сповіщення йде паралельно трьома каналами — WebSocket, Telegram Bot та Push — і очікує підтвердження. Потенційна економія від своєчасного сповіщення може сягати десятків тисяч доларів на місяць на великих портфелях. В одному з проєктів клієнт заощадив 35 000 доларів за перший місяць використання нашої системи, уникнувши ліквідації по 50 ETH.

Які проблеми вирішує система сповіщень для трейдерів

Проблема 1. Гарантована доставка. Навіть при падінні сервера або мережі клієнта повідомлення не повинно пропасти. Використовуємо черги з персистентністю та retry-механізми. Проблема 2. Latency. Для P0-подій (ліквідація, margin call) потрібна доставка менш ніж 100 мс. Тільки паралельна відправка через кілька каналів дає такий результат. Проблема 3. Масштабування. При зростанні кількості користувачів навантаження на канали зростає нелінійно. Потрібен асинхронний event bus з шардуванням.

Як гарантувати доставку при ліквідації?

Пріоритетна черга — основа архітектури. Подія P0 fan-out'иться у всі канали: WebSocket, Push, Telegram. Система чекає хоча б одного підтвердження. Якщо канал недоступний, повідомлення зберігається в Redis і доставляється при відновленні. Це дає latency <100 мс у 99.9% випадків.

Архітектура: event bus та пріоритети

В основі — event bus з пріоритетною чергою. Кожна подія отримує пріоритет (P0/P1/P2) та набір каналів. Для P0 використовуємо synchronous fan-out: відправляємо у всі канали одночасно і чекаємо хоча б одного підтвердження. Для P1 та P2 — async fire-and-forget. Приклад роутера:

from enum import Enum from dataclasses import dataclass class NotificationPriority(Enum): CRITICAL = 0 HIGH = 1 NORMAL = 2 @dataclass class NotificationEvent: user_id: str event_type: str priority: NotificationPriority data: dict channels: list[str] # ['websocket', 'push', 'telegram'] class NotificationRouter: async def route(self, event: NotificationEvent): prefs = await self.db.get_notification_prefs(event.user_id) channels = self.select_channels(event, prefs) tasks = [] for channel in channels: handler = self.channel_handlers[channel] tasks.append(handler.send(event)) if event.priority == NotificationPriority.CRITICAL: results = await asyncio.gather(*tasks, return_exceptions=True) await self.log_delivery(event, results) else: asyncio.gather(*tasks) 

Які канали доставки найефективніші?

Розглянемо кожен канал детально.

WebSocket (in-app)

Використовуємо асинхронний менеджер з'єднань. При підключенні користувача доставляємо накопичені сповіщення. Якщо з'єднання розірвано, повідомлення зберігаються в Redis для подальшої відправки.

class WebSocketNotificationHandler: def __init__(self, connection_manager): self.connections = connection_manager async def send(self, event: NotificationEvent): connection = self.connections.get_user_connection(event.user_id) if not connection: await self.store_pending(event) return try: await connection.send_json({ 'type': 'notification', 'event': event.event_type, 'data': event.data, 'priority': event.priority.value, 'timestamp': datetime.utcnow().isoformat() }) except ConnectionClosed: await self.store_pending(event) async def deliver_pending_on_connect(self, user_id: str, connection): pending = await self.db.get_pending_notifications(user_id, limit=50) for notif in pending: await connection.send_json(notif.to_dict()) await self.db.mark_delivered(user_id, [n.id for n in pending]) 

Push (Firebase FCM)

За визначенням Wikipedia, push-сповіщення — це технологія доставки даних без запиту клієнта. Для кожної події формуємо нативне сповіщення з урахуванням пріоритету. Критичні — з priority=high в Android та apns-priority=10 для iOS. Невірні токени автоматично чистимо.

Telegram Bot

Telegram — один із найшвидших та найнадійніших каналів. Бот надсилає форматовані повідомлення з емодзі, а для критичних подій — ще й репости в особистий чат.

Як налаштувати Price Alert Engine?

Алерти на ціну кешуються за символами. При оновленні ціни перевіряємо всі тригери та надсилаємо сповіщення. Підтримуються одноразові та повторювані алерти.

Порівняння каналів доставки

Гнучкі налаштування алертів користувача

Користувач може налаштувати кожен тип подій: увімкнути/вимкнути, вибрати канали, встановити поріг спрацювання та тихі години. Критичні сповіщення (P0) тихі години ігнорують. Така гнучкість знижує рівень відписок та підвищує задоволеність.

Що входить в роботу та терміни

Ми пропонуємо розробку системи сповіщень під ключ за 30–45 днів. У вартість входить:

Загальний термін — від 30 до 45 робочих днів залежно від кількості каналів та вимог до масштабу. Команда має понад 5 років досвіду в блокчейн-інфраструктурі та більше 30 успішних проєктів.

Чому варто обрати нас

Досвід експлуатації високонавантажених систем підтверджений реальними проєктами: ми знаємо, як спроектувати архітектуру, яка не впаде при пікових навантаженнях. У роботі використовуємо сучасний стек: Firebase Cloud Messaging для push-сповіщень та Telegram Bot API для миттєвої доставки. Середня економія клієнтів на ліквідаціях завдяки своєчасним алертам становить до 20 000 доларів на місяць. Ми безкоштовно оцінимо ваш проєкт — напишіть нам для консультації. Замовте розробку системи сповіщень під ключ прямо зараз.