Чому інтеграція з агрегатором курсів зриває видачу
Розходження курсу виникає на стику двох різних уявлень про ціну. Агрегатор опитує джерела зі своєю частотою і кешує відповідь на вітрині, а обмінник у момент виконання перераховує курс за своїм стаканом.
Між показом і підтвердженням минає від секунди до кількох, і на волатильному ринку цього достатньо, щоб розходження курсу вийшло за допустимий поріг. Користувач бачить одну цифру, за фактом погоджується на іншу — і заявка або відхиляється, або йде в підтримку.
Відхилені заявки рідко бувають наслідком однієї причини. Зазвичай це набір: ліміт за резервом у партнера, непройдена перевірка, обмеження за регіоном і різні коди помилок, які агрегатор не розбирає.
Він віддає загальне «недоступно» на вітрину, а клієнт іде до наступного обмінника, хоча угода була технічно можливою.
Задвоєні заявки — окремий клас. Під час обриву з’єднання клієнт або сам агрегатор повторює запит, а якщо в пари немає узгодженого ключа ідемпотентності, одна операція перетворюється на дві. Якщо обмінник виконує обидві — отримуємо подвійну угоду і розгляд замість обміну.
Пікове навантаження розкриває все відразу. Сплеск під час різкого руху ринку дає десятки запитів за секунду, ліміти партнера спрацьовують, частина відповідей приходить із таймаутом. Заявки зависають у невідомому статусі, і ніхто не може сказати, виконана вона чи ні. Розбираємо, як це закривається.
Що змінюється в обміннику після підключення потоку
Оновлення курсу перестає бути ручною операцією: агрегатор віддає потік за підпискою, і вітрина отримує значення в межах секунд після публікації в джерелі.
Між ними — нормалізація (агрегатори вважають курс по-різному: з комісією мережі, напрямом угоди, мінімальною сумою) і дельта-фільтр, який не смикає вітрину на шумових коливаннях.
Значення проходить перевірку на розрив: якщо курс вийшов за межу відхилення, публікації немає, а в моніторинг іде подія.
Конверсія заявок зростає не від «кращого курсу», а від його узгодженості. Клієнт бачить цифру, вона фіксується на час оформлення і потрапляє в розрахунок без розходжень — саме різниця між вітриною і фактичним виконанням давала основну частку покинутих форм.
Автоматичне закриття заявок тримається на статусній моделі: створення, резерв, оплата, підтвердження в мережі, видача.
Події від провайдера і вузла обробляються ідемпотентно, тому повтор не створює другу заявку, а в ручний розбір ідуть лише випадки з сумою, що не зійшлася, або мовчанням джерела.
Стійкість до навантаження — це передбачувана деградація, а не «сервер потужніший». Заявки йдуть через чергу, ліміти за акаунтом і напрямом перевіряються на вході, а за недоступності агрегатора вітрина працює за останнім валідним курсом з явною ознакою застарівання. Пік трафіку призводить до сповільнення обробки, а не до подвійних списань і загублених заявок.
Після підключення дивимося на чотири величини: затримку від публікації курсу до вітрини, частку заявок, закритих без оператора, частку покинутих форм і кількість відмов через розходження курсу. Це і є вимірюваний зсув, який видно при порівнянні до і після.
Способи підключення: від готового модуля до власного шлюзу
У обмінника є три принципово різні шляхи в агрегатори курсів, і вибирають між ними не за популярністю рішення, а за обсягом заявок і за тим, хто відповідає за розходження котирувань.
Нижче — порівняння варіантів підключення з їхніми обмеженнями, щоб схема збігалася з навантаженням, а не навпаки.
Ключова відмінність схем у тому, де живе логіка зіставлення курсу і статусу заявки. У готовому модулі її тримає майданчик, у власному шлюзі — ви, а в посередника з ліквідності вона розмазана між сторонами. Від цього залежить, як швидко ви побачите розходження і чи зможете відкотити помилкове котирування.
| Варіант | Коли підходить | Обмеження схеми |
|---|---|---|
| Готовий модуль агрегатора | Невеликий і середній потік заявок, потрібен швидкий старт без своєї інфраструктури | Логіка курсу і повторів запитів чужа: правила оновлення задає майданчик, тонке налаштування статусів недоступне |
| Власний шлюз до API майданчиків | Щільний потік і кілька агрегаторів одразу, потрібен єдиний журнал заявок та ідемпотентна обробка | Потребує своєї черги, контролю частоти запитів і чергування на розходженнях |
| Посередник з ліквідності | Потрібен доступ до глибини ринку і швидке розширення списку майданчиків | Зайва ланка в ланцюжку: довше підтвердження, складніше розібрати інцидент за конкретною угодою |
| Прямі домовленості з майданчиком | Великий обсяг і жорсткі вимоги до маржі | Тривалі переговори й окрема інтеграція під кожного партнера |
Обмеження схеми проявляються не на старті, а на піку навантаження: коли майданчик змінює формат відповіді, частина заявок зависає в проміжному статусі.
Тому варіант підключення фіксуємо до розробки — за кількістю майданчиків, очікуваним потоком і тим, хто чергує на розходженнях курсу.
Етапи інтеграції: від схеми обміну до передавання
Інтеграція з агрегатором курсів — це не «підключити API і віддати курс». Агрегатор приводить потік, і розходження між курсом на його вітрині й фактичними умовами угоди в обміннику одразу б’є по конверсії. Тому етапи інтеграції вибудувані так, що кожен закінчується перевірюваним результатом, а не звітом.
- Аудит схеми обміну. Розбираємо джерела курсу, пріоритет між ними, ручні правки, округлення і спред. На виході — карта потоку і список розходжень з фактичними умовами угоди.
- Проєктування схеми. Вибираємо модель: опитування за розкладом або передавання за подією. Задаємо порядок джерел, поведінку за недоступності одного з них і правило, за яким курс вважається застарілим.
- Налаштування і тестовий контур. Піднімаємо ізольований контур із тестовим середовищем агрегатора: мапінг полів, обробка помилок і лімітів, дедуплікація повторів, журнал відповідей для звірки.
- Навантажувальна перевірка. Проганяємо профіль трафіку агрегатора зі сплесками і дивимося поведінку при затримках: віддаємо останній підтверджений курс або позначаємо його як неактуальний.
- Приймальні сценарії. Звіряємо курс за всіма парами з еталоном, перевіряємо часткову недоступність джерела і відкат на попередню схему обміну.
- Перемикання потоку. Переводимо трафік частками, порівнюючи частку відмов і конверсію на новому й старому каналі. Повне перемикання — після збіжності метрик.
- Приймання робіт і передавання. Віддаємо схему, регламент чергування і метрики, фіксуємо, що вважаємо інцидентом і в якому порядку реагуємо.
До перемикання потоку жоден етап не вважається завершеним «на око»: у кожного є критерій, за яким ми разом приймаємо результат.
Схеми обміну, доступи й регламенти передавання
Інтеграція вважається зданою не тоді, коли курси приходять, а коли замовник може змінювати склад джерел, не читаючи вихідний код.
Тому до кінця робіт у вас залишається комплект артефактів — його ми розбираємо на прийманні разом із вашими інженерами, а не віддаємо архівом «на пам’ять».
- Передавання налаштувань. Робочі конфігурації мапінгу: які поля відповіді агрегатора йдуть у курс, поріг розходження між джерелами, таймаути і кількість повторів запиту. До кожного параметра — коментар, що зміниться в поведінці, якщо його зсунути.
- Схема потоків. Шлях запиту від клієнта до фіксації курсу: де кеш і скільки він живе, де черга, у який момент підключається резервне джерело і коли видача блокується. З точками відмови і тим, як кожна відпрацьовує.
- Правила доступу. Ролі й області видимості: хто править список джерел і пріоритет між ними, хто змінює пороги, хто бачить лише журнал. Ключі агрегаторів — у секрет-сховищі, з ротацією і без виведення в логи.
- Документація. Опис полів і форматів відповіді, довідник кодів помилок за кожним джерелом, порядок підключення нового агрегатора — від тестового ключа до включення в бойовий відбір.
- Регламент на збій. Що робить система і що роблять люди за недоступності джерела, при розходженні курсів вище порога, при сплеску відмов. З порядком перемикання, оповіщення і зворотного включення.
- Журнал розбору. Трасування за кожним відхиленим курсом: яке джерело відповіло, за який час і за яким правилом значення не пройшло. Без цього інцидент перетворюється на листування з агрегатором.
- Тестовий контур. Записані відповіді джерел і сценарії збоїв, щоб нові правила відбору перевірялися до бойового трафіку.
Пакет оновлюємо за кожної зміни правил — інакше документація розходиться з поведінкою системи вже через місяць.
Кейс: як обмінник перестав втрачати заявки з потоку
Обмінник отримував заявки з трьох агрегаторів курсів, і кожна проходила через оператора: звірка курсу, ручне перенесення реквізитів, підтвердження угоди.
На піку це 40+ заявок на годину, і при відхиленні курсу на частки відсотка частина заявок ішла за старою ціною або губилася в листуванні — до 12% звернень на добу. Час реакції на зміну курсу сягав 15 хвилин, за зміну оператор робив близько 60 ручних правок.
Ми підключили обмінник до BestChange та інших агрегаторів напряму: єдиний сервіс курсів збирає ставки, нормалізує їх і віддає в агрегатор, а вхідна заявка створюється автоматично з перевіркою за зовнішнім ідентифікатором — дублі з різних джерел не перетворюються на дві угоди.
Відповідь агрегатора може прийти із затримкою, тому заявка ставиться в чергу, а курс фіксується на момент підтвердження, а не на момент відправлення.
Метрики до і після
Частка загублених заявок — з 12% до 1,5%. Час реакції на зміну курсу — з 15 хвилин до 20 секунд. Ручних правок за зміну — з 60 до 4, і залишилися тільки спірні випадки та великі суми.
На тому самому потоці відвідувачів оборот зріс приблизно на третину: частина заявок просто перестала йти повз.
Окремо закрили розсинхрон: журнал розходжень за курсами й оповіщення чергового при відхиленні вище порога. Кейс інтеграції показав, що вузьке місце було не в залученні трафіку, а в ручній ланці між агрегатором і ядром обмінника.
Чим пряме підключення відрізняється від роботи через посередника?
Різниця в тому, хто володіє потоком цін. При прямому підключенні обмінник сам звертається до джерел і збирає свою таблицю курсів, а при роботі через посередника отримує вже готове число — перераховане, із зашитою чужою маржею і без доступу до вихідних даних.
Контроль курсу — перше розходження. На прямому підключенні спред, крок округлення і правила реакції на волатильність задає сам обмінник: можна стиснути маржу на популярному напрямі й підняти там, де потік тонкий.
Посередник такі налаштування не віддає, він надсилає одне значення, і все, що між джерелом і цим значенням, залишається закритим.
Швидкість оновлення залежить від того, скільки шарів стоїть між джерелом і вітриною.
Пряме підключення доносить зміну курсу за один крок, у посередника додається проміжна ланка і власний буфер — на різкому русі ринку розрахунок на стороні клієнта відстає, і заявка йде за ціною, якої вже немає.
Прозорість відмов улаштована схоже. При прямому підключенні видно, яке джерело не відповіло, скільки разів і з якою затримкою, — збій локалізується і закривається точково.
Через посередника приходить помилка верхнього рівня, і незрозуміло, проблема в нього чи в контрагента: діагностика розтягується, а клієнт бачить завислий розрахунок.
Головна ціна роботи через посередника — залежність від партнера. Він змінює ліміти, склад напрямів і правила округлення в односторонньому порядку, а підключення може відвалитися без попередження.
Тому на практиці частіше беруть гібрид: ключові напрями ведуть напряму, а рідкісні закривають агрегатором як підстраховкою.
Часті питання щодо підключення і потоку заявок
Підключення до агрегаторів курсів майже завжди піднімає ті самі сумніви — про посередника, стрибки курсу і долю вже наявного потоку. Нижче — відповіді по суті, без загальних формулювань.
Ми працюємо через посередника — перехід буде болючим?
Розривати схему не потрібно: пряме підключення піднімаємо паралельно, і якийсь час обидва канали працюють одночасно.
Звіряємо курси, ліміти й статуси заявок, а посередника вимикаємо лише після збігу даних — напрям перестає втрачати на його націнці й на затримці в передаванні курсу.
Що відбувається із заявками при різких стрибках курсу?
Курс агрегатора живе обмежений час, тому заявка фіксує значення на момент підтвердження, а не на момент запиту. При русі ринку спрацьовує поріг відхилення: угода не закривається за застарілою ціною, а перераховується або повертається клієнту.
Скільки триває підключення і що з поточними заявками?
Типовий строк — від двох до чотирьох тижнів: доступи й зіставлення валютних пар, потім тестовий контур і виведення в робочий потік. Дійсний канал увесь цей час приймає заявки як завжди, історія і статуси залишаються на місці, а новий контур вводимо часткою трафіку.
Як відсікається сміттєвий потік?
На вході — правила за сумою, валютною парою і частотою звернень, на виході — звірка з репутаційними мітками майданчика. Заявка, що не пройшла поріг, не доходить до оператора, і частка скасованих угод падає в рази.
Обговоримо задачу і повернемося з оцінкою та планом
Щоб повернутися з оцінкою робіт і планом підключення, а не із загальними формулюваннями, нам потрібна картина вашої поточної схеми обміну з агрегаторами курсів. Чим точніші вихідні дані, тим менше припущень у кошторисі й тим передбачуваніший перший реліз.
- Які агрегатори курсів уже підключені і за якою моделлю: перехід за посиланням, отримання курсу через програмний інтерфейс, пряме передавання заявок. Позначте, де впираєтеся в обмеження за частотою звернень.
- Формат обміну: як приходять курси, ліміти й напрями, як часто оновлюється кеш і що відбувається на стороні обмінника при розсинхроні даних із джерелом.
- Обсяги потоку: скільки напрямів і валютних пар у роботі, скільки запитів за хвилину приходить у піку, яку частку становлять відмови на поточних зв’язках.
- Як вважається конверсія: у якій точці фіксується перехід до вас і на якому кроці втрачається основна частина потоку.
- Правила перерахунку: округлення курсу, комісії, мінімальні та максимальні суми, порядок обліку при різкому русі ринку.
- Доступи й тестові середовища агрегаторів, ліміти на запити, порядок узгодження викатки на бойовий контур.
- Відповідальні з обох сторін і допустиме вікно простою при перемиканні трафіку.
З цим набором наші інженери збирають схему обміну, відзначають вузькі місця і визначають, що закривається штатними засобами агрегатора, а що потребує окремого шару.
Опишіть задачу в зручному вигляді — повернемося з оцінкою робіт, планом підключення за етапами і списком ризиків, які варто зняти до старту.
