Система моніторингу криптовалют: де розходяться курси
Одна й та сама пара на двох майданчиках в один момент показує різні цифри. На ліквідних інструментах розходження котирувань вимірюється частками відсотка, на тонких — розходяться в рази, і формально обидва майданчики праві: у кожного своя книга заявок і своя остання угода.
Поки оператор звіряє значення вручну через вебінтерфейси, ринок іде, а рішення ухвалюється за цифрою, якої вже не існує.
Причина — в будові джерел ринкових даних. Спотовий стакан дає миттєву, але вузьку картину одного майданчика; індексний агрегатор усереднює кілька бірж і відсікає викиди, тому його значення завжди відстає; позабіржові та розрахункові котирування надходять дискретними зрізами.
Затримка оновлення курсу складається з інтервалу публікації, часу доставки й моменту, коли значення зафіксували у себе.
Далі з’являється ціна помилки: спрацьований ризик-контроль на одному джерелі мовчить на іншому, звітність не сходиться між підрозділами, а арбітражна різниця, добре видима на історичному графіку, в моменті недосяжна.
Актуальність курсу — це не «плюс-мінус секунда», а відповідь на питання, до якого моменту часу прив’язана конкретна цифра.
Курси криптовалют у реальному часі — задача не про «показати число», а про те, щоб кожне значення несло позначку джерела, часу та методики розрахунку.
Розбираємо, як це закривається: нормалізація потоків, вибір опорної ціни та правила, за якими розходження стає видимим сигналом, а не сюрпризом у звіті.
Що дає потік котирувань у реальному часі
Ручна звірка курсів за кількома майданчиками тримається рівно до першого спалаху волатильності: ціни розходяться, частина екранів показує застаріле значення — і рішення ухвалюється за ним.
Єдине джерело даних прибирає саму можливість такого розходження: потік котирувань надходить в одну нормалізовану стрічку, де в інструмента одна ціна й одна позначка часу.
Що знімається разом із ручною звіркою
Далі ефект видно за поведінкою системи під навантаженням, а не за обіцянками:
- Єдине джерело даних — замість окремого з’єднання з кожним майданчиком одна стрічка; розходження між вітринами не виникає за побудовою.
- Пропуски в даних — обрив з’єднання закривається перепідключенням із добором випалого відрізка, графік не рветься на очах користувача.
- Усунений клас відмов — розсинхронізація вітрини й розрахункового модуля: обидва читають один потік, а не свої копії.
- Швидкість реакції на ринок — від угоди на майданчику до оновлення на екрані минають секунди замість хвилин ручного оновлення.
- Пікова волатильність — сплеск активності не обвалює потік: черга розбирається за пріоритетами інструментів.
- Спостережуваність — журнал затримок і оповіщення на розрив потоку окремо для кожного інструмента.
Для звірки історичних рядів підключаємо зовнішній агрегатор, наприклад CoinGecko, але операційним джерелом залишається прямий потік із майданчиків: агрегатор віддає дані із затримкою і не годиться там, де потрібна реакція на рух у моменті.
Варіанти збору даних: опитування, потік, гібрид
Три способи отримати ринкові дані розрізняються не «швидкістю», а профілем відмови та вартістю підтримки. Збір даних за розкладом простий у налагодженні: один запит — один знімок стану, легко відтворити й звірити з історією.
Потоковий канал віддає зміни одразу й дає меншу затримку, але вимагає постійно тримати з’єднання, обробляти обриви й відновлювати пропущений інтервал.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Опитування за розкладом | Аналітика, портфель, оповіщення, де затримка в секунди не критична | Пропуск руху всередині інтервалу, ліміти джерела, зростання навантаження при частому опитуванні |
| Потоковий канал | Стакан, тіки, арбітраж, швидкі оповіщення за ціною | Обриви й дублі подій, складніше тестувати, потрібне довантаження історії |
| Гібридна схема | Продакшн з вимогою безперервності даних | Два маршрути, звірка джерел і єдина модель подій |
Гібридна схема збору
На практиці обирають гібридний варіант: потоковий канал тримає актуальну ціну, а збір даних за розкладом працює як резервний маршрут і дозаповнює пропуски після обриву.
Обидва джерела приводяться до однієї моделі події з позначкою часу й ознакою походження — розрахунковий модуль не знає, звідки прийшла ціна. Якщо потік мовчить довше за поріг, перемикач переходить на опитування, а при відновленні звіряє останні значення й гасить розходження.
Етапи робіт: від аудиту джерел до передачі
Роботу над системою моніторингу криптовалют ведемо етапами, і кожен етап закривається перевірюваним артефактом: переліком джерел, схемою, працюючим контуром збору або протоколом випробувань. Прогрес видно за фактом, а вимоги можна виправити до того, як вони перетворяться на переробку.
- Аудит джерел даних. Звіряємо торгові майданчики й агрегатори за повнотою віддачі та стабільністю, перевіряємо розходження в позначках часу. Фіксуємо придатні джерела й запасні на випадок відмови основних.
- Схема потоків. Маршрут даних від приймання до вітрини: де нормалізація, де агрегація, де зберігається історія і за якими правилами відсікаються викиди.
- Налаштування збору. Приводимо інструменти, валютні пари й позначки часу до єдиного вигляду, налаштовуємо дедуплікацію угод і відновлення пропусків після обривів зв’язку.
- Перевірка на збоях. Вимикаємо джерело, вносимо затримку, подаємо сплеск активності — дивимося, чи перемикається контур на резерв і чи не втрачає історію.
- Навантажувальна перевірка. Проганяємо контур на обсягах, вищих за очікувані, і заміряємо, як зростає затримка оновлення в піку та чи відновлюється вона після спаду.
- Спостережуваність. Метрики й оповіщення для кожного джерела, окремий контроль розходжень між майданчиками, щоб викривлення ціни не пішло в розрахунок непоміченим.
- Приймання та передача. Демонстрація на реальних даних, документація щодо конфігурації, регламент дій при збої, навчання вашої команди.
Після передачі залишаємося на зв’язку в узгодженому періоді супроводу — цей час іде на тонке налаштування, а не на нові вимоги.
Схеми, політики доступу та регламенти на виході
Після завершення проєкту в замовника залишається не лише працюючий сервіс, а й комплект артефактів, за якими систему можна розвивати власними силами або передати іншій команді без розбору коду. Ми фіксуємо їх наприкінці робіт і синхронізуємо з фактичним станом стендів, а не з чернетками.
- Схема інтеграції — потоки котирувань від джерел до підписників, точки перемикання на резервний канал, формати повідомлень і заявлена частота оновлення.
- Політики доступу та ролі — матриця прав: хто додає джерела, хто бачить службові метрики, хто зупиняє розрахункові задачі. За замовчуванням діє принцип найменших привілеїв.
- Регламент реакції на збої — рівні інцидентів, пороги оповіщення, порядок дій чергового, час перемикання на резервне джерело та умови повернення.
- Документація на рішення — опис компонентів, межі відповідальності між сервісами, відомі обмеження та ухвалені компроміси з обґрунтуванням.
- Інструкція з відновлення — покроковий сценарій підйому з резервної копії з фактично заміряним часом, а не розрахунковим.
- Набір перевірок — автоматичні тести на розрив потоку котирувань, розходження цін між джерелами та відставання оновлень.
- Журнал змін і передача — розбір архітектури з вашою командою, відповіді на питання щодо коду та список задач, відкладених усвідомлено.
Комплект перезбирається при кожній суттєвій зміні потоку даних: застаріла схема небезпечніша за її відсутність, бо за нею ухвалюють рішення.
Кейс: моніторинг курсів без розходжень на піках
Сервіс збирав котирування з 14 джерел і складав їх в одну таблицю. На спокійному ринку розходжень не було видно, але при різкому русі ціни за одним інструментом розходилися до 1,2% — користувач бачив курс, якого на ринку не існувало. У моменти сплесків частина опитувань не встигала відпрацювати, і дані просто випадали з потоку.
Ми замінили періодичні опитування на постійно відкриті потокові канали й додали шар нормалізації: приведення джерел до єдиної шкали часу, дедуплікація повторних тіків, відсів викидів за медіаною сусідніх вікон.
Кожне значення зберігає позначку джерела й час події, тому розходження тепер видно у звіті, а не в інтерфейсі клієнта.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Джерел у потоці | 14 | 38 |
| Розходження на піках | до 1,2% | 0,05% |
| Затримка від події до графіка | 4–7 с | до 1 с |
| Втрата тіків при сплеску | 0,3% | 0,01% |
| Відновлення після збою джерела | близько 20 хв | близько 40 с |
Окремо закрили відмовостійкість. Раніше падіння джерела зупиняло графік до ручного втручання: черговий помічав завмерлий потік за скаргою.
Тепер перемикання на резервний канал займає десятки секунд, а споживачі підписки не розриваються — сервіс продовжує віддавати дані тим самим клієнтам.
Підсумок кейсу моніторингу курсів — не лише цифри стабільності потоку. Шар перевірок порівнює ціни між джерелами, позначає арбітражні аномалії та піднімає оповіщення при стійкому розходженні.
Клієнт бачить одну ціну із зазначенням, скільки джерел її підтвердили, і це зняло основну частину звернень у підтримку.
Чим потік відрізняється від періодичного опитування
Потік надсилає подію на кожну зміну ціни, періодичне опитування — знімок із фіксованим кроком. При кроці в 30 секунд перепад усередині інтервалу не видно, і метрики — волатильність, сплески обсягу, спрацьовування порогів — рахуються за викривленим рядом. Для вітрини курсів це непомітно, для алертів і перерахунку позицій — критично.
Але потік не скасовує опитування. Постійне з’єднання рветься при деградації мережі та на боці джерела, а пропущену подію легко прийняти за «ціна не змінювалася».
Опитування ідемпотентне: повторний запит повертає той самий стан, і відновлення після збою не вимагає наздоганяти історію.
Частота оновлення — не самоціль: джерела розрізняються за гранулярністю. Агрегатори на кшталт CoinGecko віддають усереднені значення із затримкою, біржові канали — кожну угоду.
Режим підбираємо під джерело й задачу: де немає широкомовного каналу, будуємо опитування з адаптивним кроком під поточну волатильність.
Окрема стаття витрат — підтримка. Потік вимагає буферизації, відсіювання дублів і контролю порядку подій, опитування — планувальника з повторами та паузами.
Гібрид закриває обидва слабкі місця: потік тримає актуальність, а знімок раз на кілька хвилин звіряє ряд з еталоном і підтягує пропущене після розриву.
Часті технічні питання щодо інтеграції
Питання щодо інтеграції зазвичай виринають на етапі, коли збір котирувань уже розгорнуто й працює: потрібно зрозуміти, як вбудуватися в наявний контур, не ламаючи його. Шар розрахунку надбудовується поверх поточного збору — переписувати працюючі частини не потрібно.
Нижче — чотири сумніви, які ми розбираємо до старту: відмова майданчика, різна затримка джерел, достовірність курсу та права на результат.
Що буде, якщо майданчик перестане віддавати дані?
Кожне джерело ізольовано: обрив з’єднання не зупиняє інші канали. Підключення відновлюється з наростаючою паузою, а стан курсу тримається на останньому підтвердженому значенні з позначкою про його давність.
Якщо майданчик мовчить довше за заданий поріг, він виключається з розрахунку — підсумкове значення продовжує рахуватися за живими джерелами.
Як рахувати курс, якщо майданчики віддають дані з різною затримкою?
Значення прив’язується до позначки часу самого майданчика, а не до моменту приймання, тому розкид затримок не зсуває картину. Розрахунок іде за ковзним вікном: канали, що випали з нього, до підсумку не потрапляють. У відповіді видно, за яким набором джерел пораховано курс.
Звідки впевненість, що курс достовірний?
Кожне значення — зведення кількох незалежних майданчиків з відсіканням викидів і допуском на розходження між ними. Якщо джерела розходяться сильніше за поріг, значення позначається як спірне, а не віддається як факт. Пороги налаштовуються під ваш профіль активів.
Кому належать код, схеми та документація?
Права передаємо замовнику: вихідники, схеми потоків і даних, конфігурації, документація та регламенти розгортання. Система працює у вашому контурі й не залежить від нашого середовища — супровід можна вести силами своєї команди.
Що потрібно для старту і як ми рахуємо оцінку
Оцінка робіт спирається на вихідні дані щодо задачі, а не на усереднені припущення: від кількості джерел і вимог до свіжості котирувань залежить і склад системи моніторингу криптовалют, і трудовитрати. Тому починаємо з короткого переліку того, що надсилаєте зі свого боку.
- Перелік майданчиків: звідки беремо котирування — відкриті інтерфейси, агрегатори, власні вузли.
- Доступи до джерел: ключі, ліміти запитів, вимоги до ідентифікації, обмеження за частотою.
- Інструменти та пріоритети: які пари потрібні, за якими рахуємо зведену ціну, які довідкові.
- Вимоги до свіжості: яку затримку вважаєте робочою і що робити при розходженні джерел.
- Точки виведення: панель, застосунок, зовнішня підписка — хто дивиться дані й які дії виконує.
- Навантаження та історія: скільки одночасних підключень очікуєте, за який період зберігаємо котирування.
- Поведінка при збоях: що показувати, якщо майданчик недоступний, чи потрібен перехід на резервне джерело.
З цим набором ми розбираємо потоки даних між джерелами, сховищем і клієнтськими екранами, позначаємо вузькі місця й повертаємося з планом та оцінкою строків: що робимо на першому етапі, що відкладаємо, які перевірки закладаємо.
Якщо частина даних поки закрита, фіксуємо припущення прямо в оцінці. Опишіть задачу у вільній формі — решту уточнимо в розмові, а потім повернемося зі складом робіт і строками.
