Time & Sales стрічка: де вона ламається під навантаженням
Стрічка Time & Sales — це потік усіх виконаних угод: ціна, обсяг, сторона ініціатора.
На спокійному ринку вона виглядає нешкідливо, але саме вона першою впирається в межі інфраструктури на піковому потоці заявок, коли модуль виконання видає події швидше, ніж їх встигають доставити й відмалювати.
Пропуски угод майже ніколи не означають втрату даних на боці біржі — втрачається доставка. Якщо споживач не підтверджує обробку, а черга зростає швидше, ніж розбирається, буфер переповнюється і частину повідомлень відкидають.
У стрічці це виглядає як розрив нумерації: обсяги в книзі заявок уже змінилися, а угод, які їх змінили, клієнт не побачив.
Розсинхрон потоку виникає на стику відновлення після обриву зв'язку. Клієнт бере знімок стану й наздоганяє його порціями змін, але поки знімок застосовується, частина змін уже застаріла або прийшла з іншим порядковим номером.
Без строгого контролю неперервності послідовності стрічка тихо роз'їжджається з реальним станом книги — зовні жива, але з невірними обсягами й ціною останньої угоди.
Затримка відгуку й зависання інтерфейсу — третя точка відмови, і живе вона на боці клієнта.
Відмальовування кожної угоди окремим оновленням на піку тримає головний потік обчислень зайнятим, накопичені оновлення зливаються в чергу, і стрічка перестає реагувати на дії трейдера — аж до перезавантаження вкладки.
Розбираємо, як це закривається: підтвердження обробки на кожній ділянці шляху, контроль неперервності послідовності, обмеження черги з явним сигналом про перевантаження й пакетне відмальовування кадрами замість оновлення на кожну подію.
Ефект впровадження: відгук, повнота, стійкість до піків
Після запуску власної стрічки змінюється не оформлення інтерфейсу, а поведінка системи під навантаженням. Потік угод іде напряму від торгового ядра й роздається підписникам, тому повнота даних і відгук інтерфейсу перестають залежати від зовнішнього постачальника та його затримок. Ефект впровадження видно у вимірюваних показниках, а не в загальних словах.
| Що вимірюємо | До впровадження | Після впровадження | Спосіб перевірки |
|---|---|---|---|
| Повнота даних | пропуски угод при обриві з'єднання | звірка сходиться після будь-якого обриву | лічильники угод на джерелі та в стрічці |
| Відгук інтерфейсу | просідання на пікових потоках | рівне відмальовування під піком | замір від події до появи рядка |
| Стійкість до піків | зростання черги, підвисання | сплеск гаситься буфером, потік не рветься | прогін запису реальних піків |
| Час відновлення | ручний перезапуск і дозаливка | автоматичний дозалив пропущеного | час від збою до збігу лічильників |
Метрики знімаються безперервно з двох боків — на сервісі роздачі та на клієнті: панелі моніторингу в Grafana, алерти на розходження лічильників і на зростання часу відновлення.
Розходження хоча б в одну угоду стає приводом для розбору, бо стрічка бере участь у звірці та аудиті історії торгів.
Стійкість до піків перевіряється не на око, а прогоном записаного потоку: сервіс зобов'язаний пережити сплеск без втрати рядків і без зростання затримки відмальовування.
Після обриву стрічка наздоганяє потік сама, без дій чергового, — це і є та різниця, яку замовник бачить в експлуатації.
Формати стрічки: потік угод, агрегація, снапшоти
Формат стрічки визначає, що саме отримує клієнт: кожну угоду окремо, агреговані інтервали або зріз історії на момент підключення. На біржі ці режими співіснують, і вибір між ними — компроміс між повнотою даних, навантаженням на канал і затримкою доставки.
Потік угод іде постійним з'єднанням: ціна, обсяг, сторона ініціатора та ідентифікатор послідовності в кожному повідомленні. Агрегація угод збирає їх в інтервали — вікно агрегації налаштовується від часток секунди до хвилини: ширше вікно, менше повідомлень і вища затримка реакції.
Снапшоти історії закривають підключення та розрив каналу: клієнт забирає зріз за потрібний діапазон і продовжує з того місця, де зупинився, без пропусків і дублів.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Потік угод | Термінали, торгові роботи, аналітика в реальному часі | Обрив каналу вимагає повторного довантаження |
| Агрегація угод з вікном | Графіки, мобільні клієнти, моніторинг | Втрачається деталізація, точний перерахунок неможливий |
| Снапшоти історії | Підключення, вивантаження, аудит, розбір інцидентів | Не підходить для живої торгівлі, обсяг зростає з діапазоном |
У робочому контурі режими комбінуються: снапшот при підключенні, потім догін потоком за ідентифікатором послідовності.
Тому формат стрічки ми узгоджуємо із замовником до початку роботи — від нього залежить і схема зберігання, і те, як клієнт переживає розрив з'єднання без втрати угод.
Порядок робіт: аудит потоку, схема, збирання, перевірка
Роботи йдуть етапами, і після кожного залишається перевірюваний артефакт: карта джерел, специфікація моделі, працюючий сервіс, звіт звірки. Так ви бачите рух по задачі й можете скоригувати вимоги до того, як вони перетворилися на код.
-
Аудит джерел. Інвентаризуємо майданчики: спосіб доставки угод, частоту оновлень, глибину потоку, поведінку в години пік. Відзначаємо, де дані розходяться з біржовим агрегатором, і заздалегідь вирішуємо, чим закривати ці розходження.
-
Схема даних. Описуємо єдину модель угоди: ціна, обсяг, сторона агресора, мітка часу, ідентифікатор майданчика, ознака скасування. Правила нормалізації зводять різні формати до одного контракту — стрічка перестає залежати від конкретного джерела.
-
Збирання сервісу. Реалізуємо підписку, буферизацію, дедуплікацію та перепідключення з догоном пропущеного вікна: обрив зв'язку не залишає діри в стрічці. Публікацію налаштовуємо так, щоб затримка від угоди до запису залишалася передбачуваною.
-
Перевірка на історії. Прогонимо сервіс на архівних даних і звіряємо з еталонною стрічкою майданчика: шукаємо пропуски, дублі, порушення порядку, розходження міток часу. Кожне розходження розбираємо до причини — у коді чи в самому джерелі.
-
Випробування на збоях. Емулюємо сплески активності, розрив з'єднання, рестарт вузла й дивимося, чи відновлюється стрічка без втрат. За підсумками налаштовуємо сигнали, за якими черговий бачить деградацію раніше за користувача.
-
Приймання робіт. Передаємо конфігурації, схему, метрики та інструкцію з експлуатації, розбираємо з вашою командою типові інциденти. Далі — супровід: правки під зміни на майданчиках і розбір спірних випадків звірки.
Комплект передачі: сервіси, схеми, регламенти, доступи
Роботи закінчуються не демонстрацією, а передачею: замовник отримує не лише працюючий потік угод, а й усе, що потрібно для самостійної експлуатації та розвитку стрічки.
Комплект зібрано так, щоб чергова зміна могла підняти сервіс без авторів, а новий інженер — розібратися в архітектурі за документами, а не за листуванням.
- Комплект документації: опис топології сервісів, форматів повідомлень і гарантій доставки — включно з поведінкою при обриві з'єднання та перепідключенні з довантаженням пропущених угод.
- Схеми інтеграції: діаграми потоку від торгового ядра до клієнтських підписників, точки підключення, порядок маршрутизації та правила нормалізації даних за інструментами.
- Регламент експлуатації: порядок планових робіт і вікна обслуговування, процедура викочування нової версії та відкату на попередню, критерії обов'язкової ескалації інциденту.
- Політики доступу: ролі й права на промисловий і тестовий контури, видача та відкликання ключів, розділення доступу до торгового ядра й до вітрини історичних даних.
- Інструкції для чергової зміни: покрокові сценарії на типові відмови — зростання затримки публікації, лавина перепідключень, розходження стрічки з ядром, деградація каналу.
- Моніторинг і оповіщення: набір метрик (повнота потоку, затримка, частка відкинутих повідомлень), пороги спрацювання та адресати повідомлень.
- Протоколи приймання: результати навантажувальних і відмовостійких прогонів плюс контрольний список перевірки після кожного релізу.
Обсяг документації не «про всяк випадок»: кожен артефакт закриває конкретний клас відмов, який інакше коштує годин простою біржі. Комплект передаємо на зустрічі з розбором, а не архівом — щоб чергова зміна та ваш інженер поставили питання по живому.
Кейс: піковий потік угод і час відновлення
Біржа з різкими сплесками активності: лістинги, каскадні ліквідації, новинні імпульси.
Середній потік угод у стрічці Time & Sales іде рівно, але на піку кратність до нього зростала в десятки разів — і саме в ці хвилини стрічка відставала найсильніше, коли дані потрібні посекундно.
До нас перепідключення клієнта йшло через повний снапшот і без дедуплікації за ідентифікатором угоди. Підсумок — або пропуск угод в історії, або дублі, а відновлення підписки займало хвилини.
Що змінили
Потік угод віддаємо через Kafka: снапшот плюс інкремент, дедуплікація за ідентифікатором угоди, серверний буфер на час перепідключення — підписка не рветься, клієнт наздоганяє пропущене сам.
Результат
Усунуто цілий клас відмов — розходження стрічки в клієнта з фактичними угодами на біржі. На пікових інтервалах затримка доставки залишилася в межах секунди й перестала зростати разом із навантаженням, а відставання стрічки більше не потребує ручного втручання чергової зміни.
Чим відрізняється потік угод від агрегованого стакана?
Потік угод, або стрічка Time & Sales, — це журнал виконань: ціна, обсяг, час і сторона ініціатора в кожному рядку. За міткою агресора видно, чи знімав покупець лімітну заявку на продаж, чи продавець бив у бід, — знімок книги заявок такого не показує.
Агрегований стакан — про наміри, а не про факти: лімітні заявки згруповані за рівнями ціни із сумарним обсягом на кожному.
Заявку можна зняти до виконання, тому стакан — стан, який перезбирається з інкрементальних змін, а потік угод — послідовність подій, зі знімка не відновлювана.
Відмінність підходів проявляється на одній і тій самій угоді. Стакан відповідає, де стоїть щільність і на якому рівні ціна зустріне опір; стрічка — як обсяг було набрано: однією великою заявкою чи серією дрібних виконань за різними цінами.
Вибір режиму диктує задача. Алгоритмам, які рахують дельту й дисбаланс агресора, потрібна стрічка з флагом сторони; оцінка ліквідності та прослизання будується за глибиною стакана. Для арбітражу й контролю якості виконання подають обидва потоки одночасно.
В інтерфейсі їх ведуть різними каналами: стрічка оновлюється на кожне виконання, стакан — рідше, за накопиченими змінами. При щільному потоці записи згортають за ціною за короткий інтервал — відмальовування перестає захлинатися, але розбивка на окремі угоди втрачається.
Технічні питання, які ставлять до старту робіт
До старту проєкту замовники перевіряють приблизно одне й те саме: чи переживе стрічка обрив зв'язку, чим підтверджується порядок угод і чи не доведеться чіпати ядро торгової платформи заради нового потоку.
Нижче — короткі відповіді за кожним пунктом, деталі розбираємо на архітектурній сесії разом із вашою командою.
Що станеться зі стрічкою при обриві зв'язку?
Сервіс веде монотонний номер подій і звіряє його з джерелом. При розриві фіксується межа останньої підтвердженої події, з'єднання піднімається заново, а пропущений інтервал добирається з журналу та снапшота стакана — у стрічці не залишається «дір» і задвоєних угод. Історія залишається безперервною навіть у моменти пікової волатильності.
Як ви гарантуєте правильний порядок угод?
Послідовність задає єдине джерело часу на боці адаптера до біржі, а не годинник браузера. Пакет, що прийшов не за порядком, потрапляє в буфер перевпорядкування і публікується лише після пропущеного, тому рядки не переставляються й не «смикаються» при відмальовуванні.
Наскільки складно вбудувати це в нашу платформу?
Підключаємося окремим сервісом до вашого каналу ринкових даних і віддаємо нормалізований потік за контрактом, узгодженим із вашою командою; сумісність із FIX і внутрішнім форматом брокера перевіряємо на стенді до релізу. Матчинг і балансові модулі не змінюємо.
Що з підтримкою після виведення в продакшн?
Залишається регламент: метрики затримки й повноти потоку, алерти на розходження з біржовим джерелом, чергування та зрозумілий порядок відкату на попередню версію. Приймання йде за ознаками — частка закритих розривів, затримка публікації, відсутність дублів у добовому зрізі.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб повернутися з оцінкою та планом, не потрібен документ на сорок сторінок — достатньо вхідних даних по задачі.
Нам важливо зрозуміти, за якими біржами й торговими парами потрібна стрічка Time & Sales, звідки беремо потік угод і як стрічка пов'язана з ордербуком і графіком: єдиним потоком чи окремими підписками.
Другий блок — експлуатаційні вимоги. Потрібно знати цільові платформи (веб, мобільні застосунки, настільний термінал), очікувану глибину історії та припустиму затримку оновлення, а також сценарії відмов: що бачить користувач при розриві каналу, розсинхроні й пропуску угод.
- список бірж і торгових пар, за якими стрічка виводиться в інтерфейс;
- джерела даних: власне ядро розрахунку угод, зовнішні канали, архів історії;
- зв'язок стрічки з ордербуком, стаканом і графіком — спільний потік чи роздільні підписки;
- цільові платформи та вимоги до відображення на кожному типі пристроїв;
- вимоги до глибини історії та частоти оновлення;
- поведінка при розривах зв'язку, розсинхроні та втрачених угодах;
- обмеження за інфраструктурою, доступами та порядком викладення оновлень.
Пропонуємо обговорити задачу у вільній формі — перелічених даних достатньо, щоб повернутися зі строками, складом робіт і зрозумілим порядком старту.
Якщо зручніше почати з малого, зберемо стрічку за однією біржею та однією парою, покажемо результат у роботі й розширимо на решту майданчиків.
