Чому REST API для крипто-даних не витримує ринкового навантаження
Шар доступу до ринкових даних проєктують першим, а ламається він першим. REST API для крипто-даних працює за схемою «запит — відповідь»: застосунок звертається до джерела за кожною котировкою й чекає на відповідь.
Поки ринок спокійний, схема виглядає робочою — затримки передбачувані, кількість звернень зростає лінійно разом із кількістю користувачів.
На піковій волатильності картина змінюється стрибком. Ліміти запитів до джерела вичерпуються за секунди, частина звернень отримує відмову, а таймаути на піковій волатильності стають нормою, а не рідкісним винятком.
Клієнт іде в повторні спроби, додає навантаження на шар доступу й замикає коло: чим більше повторів, тим менше успішних відповідей доходить до продукту.
Далі з’являються застарілі котирування у відповіді. Якщо шар доступу віддає значення з кешу, не позначаючи його вік, застосунок показує ціну, якої на ринку вже немає, — і для торгівлі або розрахунків це гірше за чесну помилку.
Додається розсинхрон: частина інструментів надходить одним каналом, частина іншим, свіжість у них різна, і звести все в один знімок ринку стає окремою задачею.
У підсумку навантаження на шар доступу зростає не від кількості користувачів, а від самої архітектури звернення до джерела: додавання серверів проблему не знімає, бо впирається у зовнішні обмеження джерела. Розбираємо, як це закривається.
Що змінюється після перебудови шару доступу до блокчейн-даних
Швидкість відповіді та стабільність під піковим навантаженням
Перебудова шару доступу починається з розділення потоків: ринкові дані — ціни, стакани, угоди — читаються з кешу поверх Redis з коротким строком життя, а запити до мережі блокчейну йдуть через чергу з обмеженням одночасних звернень до вузла.
Кешування ринкових даних знімає основну частину повторів, тому сплеск у години високої волатильності не перетворюється на чергу клієнтів, що очікують.
За нашими вимірами в чинних контурах час відповіді на часті запити скоротився кратно, а частка помилок під піковим навантаженням тримається в межах десятих часток відсотка.
Окремо закрито клас відмов через недоступність зовнішнього джерела: у разі збою провайдера запит обслуговується з останнього достовірного зрізу, підписки перепідключаються самі. Відновлення після збою джерела займає хвилини замість годин простою.
Скільки ручної роботи зникає з процесів
Раніше стійкість шару доступу трималася на людині: вона стежила за відставанням вузлів, перезапускала потоки даних, вручну звіряла розбіжності між джерелом і своєю базою.
Тепер ці операції описані правилами — контроль відставання, повторні спроби із затуханням, автоматична звірка розбіжностей і оповіщення лише про аномалії.
Скорочення ручних операцій видно за чергуваннями: години рутинних перевірок на тиждень зникають. Схема доступу, правила кешування й регламент відновлення залишаються в документації, тому результат не прив’язаний до конкретного інженера.
Режими доставки даних: опитування за запитом, потокові підписки, гібрид
Формат доставки вибирають за тим, як часто змінюються дані та скільки клієнтів читають їх одночасно. Для історії угод, агрегатів за період і звітів опитування за запитом дає передбачуване навантаження: клієнт сам задає вікно й частоту, а збій одного виклику не впливає на решту.
Для котирувань, стакана й статусів транзакцій потрібні потокові підписки — сервер віддає зміну відразу, без періоду очікування.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Опитування за запитом | історія, звіти, рідкісні оновлення | затримка дорівнює періоду опитування; за частого опитування зростає кількість зайвих викликів |
| Потокові підписки | котирування, стакан, статуси транзакцій | обмеження на кількість з’єднань; у разі обриву потрібні перепідписка й дозбирання пропущеного |
| Гібридна схема доставки | торговий інтерфейс і аналітика в одному продукті | складніша в налаштуванні та перевірці, потрібен єдиний контракт ключів між потоком і запитом |
Коли опитування за запитом дешевше в підтримці
Опитування за запитом виграє там, де дані змінюються рідше, ніж раз на кілька секунд: немає довгоживучого стану з’єднання, немає перепідписки після обриву, а налагодження йде за звичайними журналами викликів.
Відповіді кешуються на стороні сервісу, тому пік запитів від кількох клієнтів не перетворюється на пік звернень до джерела. Порівняння режимів отримання даних тут однозначно на користь простоти супроводу.
Гібридна схема: гарячі дані в потоці, історія за запитом
Гібридна схема доставки знімає головне обмеження підписок: у потоці залишається лише те, що змінюється зараз, а глибина й історія переходять у запити з посторінковою видачею. Клієнт дозбирає пропущений відрізок після перепідключення одним викликом, а не перечитує весь канал. Так інтерфейс залишається чутливим, а навантаження на сховище — передбачуваним.
Порядок робіт: аудит запитів, схема, налаштування, перевірка, передача
Йдемо за етапами так, щоб кожен наступний крок спирався на зафіксовані дані попереднього, а не на припущення.
Спочатку розбираємо фактичні звернення до джерел, потім проєктуємо схему, і лише потім налаштовуємо ліміти та черги — інакше параметри підбираються навмання й не витримують першого ж пікового навантаження.
- Аудит звернень: знімаємо лог запитів до джерел за робочий період — хто, що і як часто запитує, де дублі та холості виклики.
- Схема інтеграції джерел: для кожного типу даних визначаємо основне й резервне джерело, формат нормалізації та пріоритет у разі розбіжності значень.
- Налаштування лімітів і черг: розподіляємо квоти за споживачами, ставимо буферизацію сплесків і правило деградації, коли джерело відповідає повільно або віддає помилки.
- Навантажувальна перевірка: проганяємо профіль, близький до пікового, заміряємо затримку відповіді та частку відмов, перевіряємо, що черги розвантажуються без зростання затримки.
- Передача контуру: віддаємо конфігурації, доступи, схему й регламент реагування на збої, розбираємо з вашою командою типові інциденти.
Що перевіряємо на етапі аудиту
Тут важливі виміри, а не загальні слова: фіксуємо частоту й профіль запитів за кожним джерелом, його ліміти та фактичну затримку відповіді, відзначаємо точки відмови — джерело без резерву, жорсткий ліміт без запасу, відсутність повторів у разі обриву зв’язку.
За цими даними рахуємо запас за квотами й вирішуємо, де потрібна буферизація, а де достатньо локального кешу.
Що залишається у команди замовника: конфігурації, схеми, регламенти
На руки передається не набір доступів і усних домовленостей, а комплект артефактів, за яким ваша команда може сама підняти сервіс, підключити нове джерело й розібрати розбіжність у даних без нашої допомоги.
Склад документації, що передається
- Конфігурації сервісів: параметри середовищ, ліміти запитів, правила перепідключення підписок і таймаути.
- Схеми потоків даних: шлях від джерела через нормалізацію й кеш до точки видачі, із зазначенням місць можливих втрат і дублів.
- Матриця доступу: які сервіси та ролі до яких методів, ключів і потоків мають доступ, з розділенням читання й адміністрування.
- Документація щодо інтерфейсів: опис методів REST і каналів WebSocket, формати помилок, ліміти, приклади запитів і відповідей.
- Модель даних: єдиний формат інструмента, пари, угоди та свічки, правила зведення даних із кількох джерел.
- Опис тестового контуру: як підняти стенд і відтворити інцидент на історичних даних.
Регламенти та зони відповідальності
Окремо передається регламент оновлення джерел: порядок додавання нового джерела, перевірка сумісності формату на тестовому контурі й умови включення в робочий контур.
Там же фіксуємо межу відповідальності: що моніторить наша чергова зміна в період супроводу, а що переходить до вашої, як оформлюються зміни схеми відповіді й куди дивитися в разі розбіжності котирувань між джерелами.
Приклад впровадження: біржовий агрегатор — зростання звернень без відмов
Клієнт — біржовий агрегатор, який зводить котирування й стакан із десятків майданчиків і віддає їх зовнішнім застосункам через публічний REST API і потік WebSocket.
До зростання аудиторії система виявилася не готовою: її пробували розширювати, дописуючи нові методи API поверх спільного моноліту, і це лише посилювало проблему.
Що було до перебудови
Один сервіс поєднував збір ринкових даних, розрахунки й віддачу клієнтам, тому піковий трафік бив по всіх вузлах одразу.
Частка відмов трималася на рівні 9-14% у години високої активності, час відгуку на важких вибірках сягав кількох секунд, а ліміти й кеш оператори правили вручну — до двадцяти втручань на тиждень. Розбір інциденту займав години: не було видно, на якій ділянці загубилися дані.
Результат у вимірюваних показниках
Збір і розрахунки винесли в окремий контур, віддачу клієнтам — у свій, із незалежним масштабуванням і кешем гарячих підписок.
Частка відмов на піку — 0,2–0,4%, час відгуку під навантаженням — десяті частки секунди за пікового навантаження, що зросло втричі, ручних правок — не більше однієї-двох на місяць.
Метрики зняті з експлуатаційних панелей у Grafana, вони залишилися у замовника разом із налаштуваннями оповіщень.
У разі деградації окремого майданчика підписка не розривається: клієнт отримує дані з резервного каналу, а подія йде в лог для розбору. Цей запас міцності й дозволив нарощувати аудиторію без перегляду архітектури.
Що робити, якщо власний вузол і API вже розгорнуто
Розгорнутий власний вузол і робочий API — не привід переписувати контур цілком. Спочатку знімаємо інвентаризацію: які методи віддають трафік, хто зі споживачів на них зав’язаний, де запити йдуть напряму у вузол і на якому обсязі він починає відставати від мережі. Це дає карту рішень — що залишається як є, а що переходить під новий шар.
Ключова зміна — кеш і черга між споживачами та вузлом. Гарячі дані на кшталт балансів і останніх блоків віддаються з кешу з налаштовуваним строком життя, важкі історичні вибірки йдуть у чергу й рахуються фоном.
Підписки на події обслуговує окремий канал, тому сплеск активності не обвалює основні запити, а вузол не дублює ту саму роботу сотні разів.
Міграція без простою будується на поступовому перенесенні. Новий шар піднімається поряд зі старим, частка трафіку переводиться на нього, відповіді звіряються з попередніми на живих запитах.
Збігаються — частка зростає; розходяться — перемикання відкочується однією командою, і споживачі різниці не помічають.
Поточні інтеграції при цьому зберігаються: адреси методів і формат відповідей залишаються попередніми, змінюється лише внутрішня начинка.
Поетапне включення йде по одному методу за раз, тож продукт не залишається без даних ні на хвилину, а кожна переключена частина одразу видна в метриках.
Технічні сумніви: навантаження, збої джерела, підтримка
Перед стартом інженери замовника задають той самий набір питань: як контур поводиться в разі падіння джерела, як переконатися, що дані не загубилися в дорозі, скільки займає підключення і що буде після запуску.
Нижче — відповіді в тому вигляді, у якому ми їх даємо на технічних сесіях, з опорою на експлуатацію схожих контурів: сервіс не довіряє джерелу й перевіряє себе сам.
Що станеться, якщо джерело перестане віддавати дані?
Збій джерела не обвалює контур: запити йдуть у чергу з повторними спробами й зростаючою затримкою, а споживачі отримують останні достовірні значення з позначкою часу. Після відновлення зв’язку розбіжності дораховуються за журналом, а не затираються новим потоком.
Як перевіряєте повноту даних?
Безперервність послідовності подій, звірка агрегатів із незалежним джерелом (наприклад, CoinGecko) і частка пропущених інтервалів. Якщо розрив вищий за поріг, вікно позначається недостовірним і не йде споживачеві мовчки.
Скільки займає введення в роботу і що з підтримкою?
Перший контур на одному джерелі — дні: адаптер, схема даних, перевірки, прогін на записаному трафіку. Далі — чергування за метриками затримки й частки помилок, оновлення адаптерів при зміні формату відповідей, планові перевірки відновлення з журналу.
Як додати або замінити джерело пізніше?
Адаптер відокремлено від ядра: новий постачальник підключається зі своїм пріоритетом і правилами звірки. Заміна йде канареечно — частина трафіку на новому джерелі, порівняння метрик, потім перемикання основного.
Старт робіт: що потрібно з вашого боку і як ми повернемося з оцінкою
Щоб повернутися з оцінкою та планом робіт, а не із загальними припущеннями, нам потрібен мінімум ввідних. Частина з них про самі дані, частина — про доступи й обмеження на вашому боці.
- Перелік джерел: біржі, брокерські системи або власні сервіси, звідки беремо котирування, стакан, угоди та історію.
- Де достатньо періодичних запитів, а де потрібен постійний потік WebSocket із перепідключенням і дозбиранням пропущеного.
- Ключі до джерел у режимі лише читання, без прав на торгові операції.
- Доступ до середовища розгортання або репозиторію та розуміння, куди писати логи й метрики.
- Ліміти постачальника даних: частота звернень, глибина історії, поведінка в разі перевищення.
- Вимоги до розмежування доступу та журналювання звернень.
- Контакт з вашого боку, хто оперативно підтвердить формат полів і відповість на уточнення.
Порядок старту такий: обговорюємо задачу, фіксуємо обсяг джерел і сценарії споживання, після чого повертаємося з оцінкою та планом робіт — етапами, строками й точками приймання.
Перший етап робіт знімає головний ризик і зазвичай іде швидше за решту: описуємо ендпоїнти й формат потоку, піднімаємо каркас REST API для крипто-даних на одному джерелі, перевіряємо поведінку в разі обриву зв’язку, повтору запиту й розбіжності даних між джерелами. Далі підключаємо решту джерел за вже відпрацьованою схемою.
Опишіть задачу — які дані потрібні та хто їх споживатиме; решту уточнимо в розмові.
