Розробка автоматичного обмінника: вузькі місця та відмови
Обмінник впевнено працює на перших сотнях заявок, а ламається на зростанні. Перше вузьке місце — ручне підтвердження: поки оператор звіряє платіж і курс очима, потік заявок зростає, час відповіді сягає десятків хвилин, і клієнт іде туди, де відповіли швидше.
Друге — розсинхрон курсу. Вітрина рахує ціну за одним джерелом, виконання йде за іншим, а між котируванням і угодою минає час. На спокійному ринку це частки відсотка, на волатильності — пряма втрата на різниці котирувань, і вона накопичується з кожною угодою.
Третє — завислі заявки. Обрив зв’язку з біржею, транзакція, що застрягла в мережі, часткове виконання — і заявка залишається в статусі «в обробці». Клієнт бачить списання без зарахування, підтримка розбирає це вручну, частина коштів заморожена, а довіра до сервісу тане.
Автоматичний обмін криптовалют страждає не від відсутності коду, а від відсутності логіки відновлення. Тому розробка автоматичного обмінника починається не з інтерфейсу, а з розбору вузьких місць обмінника: як заявка отримує однозначний статус і переживає перезапуск сервісу.
Далі — як курс фіксується на момент угоди і як система сама доводить операцію до кінця або відкочує її без ручного втручання. Нижче розбираємо, як це закривається.
Що дає автоматизація обміну: вимірювані ефекти
Автоматичний обмінник — це не форма приймання заявки, а конвеєр: ордер, перевірка ризиків, підбір ліквідності, виконання та виведення за кожним активом проходять без оператора.
Час обробки заявки перестає залежати від зміни чергового і визначається глибиною черги та кількістю підтверджень у мережі — на ліквідних парах це секунди, на рідкісних активах межу задає сам ланцюжок на кшталт Bitcoin, а не наша сторона.
Ми знімаємо медіану та 95-й перцентиль за кожною парою окремо, тому вузьке місце видно до того, як його помітить клієнт.
Що змінюється у вимірюваних величинах:
- частка ручних операцій падає з «кожна заявка» до поодиноких розборів — лише спірні та великі суми, що потребують ручного підтвердження;
- доступність сервісу сягає рівня, де планові роботи й перезапуск вузла не переривають приймання заявок;
- зникає цілий клас відмов: втрата заявки під час обриву зв’язку, подвійне виконання при повторному надсиланні, зависла транзакція без статусу;
- розходження курсу між внутрішнім розрахунком і джерелом ліквідності закривається автоматично, а не ручною правкою.
Відмовостійкість обмінника тримається на трьох речах: ідемпотентність операцій, щоб повторний запит не створив другу угоду; рознесення гарячого контуру виведення та холодного зберігання; автоматична пауза за парою при розходженні балансу або курсу вище заданого порогу.
Кожна дія пишеться в журнал з ідентифікатором заявки, тому відновлення після збою — це програвання журналу, а не розбір листування.
Далі — як це влаштовано в конкретній архітектурі та які перевірки закривають ризики на старті.
Формати запуску: готове ядро, власний модуль, гібрид
Вибір формату запуску визначається не розміром бізнесу, а тим, хто відповідає за маршрутизацію заявок і наскільки нестандартна логіка зіставлення. Готове ядро обмінника закриває стандартний потік: приймання заявки, резервування ліквідності, виконання, виведення.
Власний модуль зіставлення беруть там, де правило ціноутворення не можна виразити конфігурацією — наприклад, коли курс залежить одночасно від обсягу, джерела ліквідності та рівня резерву.
Гібридна схема обміну найчастіше виграє: ядро відповідає за облік і безпеку коштів, а маршрутизація заявок і правила зіставлення живуть в окремому сервісі, який спілкується з ядром через чергу подій. Нижче — коли який формат підходить і чим за нього платять.
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Готове ядро обмінника | Швидкий запуск потоку обміну, стандартні пари та правила розрахунку | Нестандартне ціноутворення реалізується зовнішніми скриптами, їх доводиться супроводжувати |
| Власний модуль зіставлення | Логіка зіставлення — конкурентна перевага, потрібен повний контроль над виконанням | Довше виведення в прод, вищі вимоги до навантажувальних перевірок і розбору відмов |
| Гібридна схема обміну | Потрібні швидкий старт і власна маршрутизація заявок одночасно | Потребує явного контракту між ядром і сервісом та версіонування подій |
Що б не обрали, контракт на розміщення заявок фіксуємо до початку робіт — інакше зміна формату на середині проєкту перетворюється на переписування ядра.
Етапи впровадження: від аудиту потоку до передачі в роботу
Кожна наступна ітерація спирається на артефакт попередньої: без схеми маршрутизації не можна налаштовувати резерви, без налаштованих резервів — відтворювано перевіряти сценарії. Нижче — послідовність робіт, у якій ми ведемо проєкт автоматичного обмінника.
- Аудит потоку заявок. Розбираємо поточну картину: затребувані напрямки, як надходять заявки, де губляться, який обсяг система тримає в пікові години. На виході — перелік вузьких місць з оцінкою навантаження.
- Схема маршрутизації. Фіксуємо шлях заявки від входу до виконання: правила вибору напрямку, пріоритети, поведінку при розходженні котирувань між майданчиками. Схему узгоджуємо до коду — спірні місця випливають на папері, а не в роботі.
- Налаштування резервів. Визначаємо, скільки ліквідності тримати на кожному напрямку, як вирівнювати баланси і що робити при просіданні. Пороги, після яких обмінник зупиняє приймання заявок замість виконання в збиток, описуємо заздалегідь.
- Перевірка сценаріїв. Прогоняємо систему на історичних і синтетичних даних: різкі рухи ринку, часткове виконання, недоступність зовнішнього майданчика. Кожен сценарій завершується передбачувано — поверненням коштів або коректною відмовою.
- Регламенти та моніторинг. Пишемо інструкції для операторів: як читати панель моніторингу, що робити при спрацюванні оповіщення, як вручну зупинити напрямок. Оповіщення ставимо на відхилення балансу та зростання часу виконання.
- Передача в експлуатацію. Розгортаємо на вашій інфраструктурі, прогоняємо контрольний обмін, передаємо доступи, схему та документацію. Залишаємося на зв’язку в перші тижні — правки йдуть за реальним потоком заявок.
Конфігурації, регламенти та документація обмінника
Після запуску обмінника в замовника залишається повний комплект матеріалів, за якими систему можна супроводжувати й розвивати без нас.
Ми передаємо його за описом, з версіонуванням і розміткою «що змінюється при оновленні ядра» — щоб новий інженер або підрядник не розбирав поведінку обмінника методом проб. Нижче — що саме входить до комплекту.
- Документація обмінника — архітектурна схема, модель даних, життєвий цикл заявки від створення до фінального статусу, порядок оновлень і відкат на попередню збірку.
- Схеми інтеграцій — потоки між ядром обмінника, джерелами курсів, касовим модулем і платіжними рейками, з точками відмови та описаною поведінкою при недоступності кожного контуру.
- Конфігурації — параметри за кожною парою: ліміти, крок округлення, пороги допустимого розходження курсу, рівні комісій. Для кожного значення зазначено, чому вибрано саме його і на що впливає при зміні.
- Політики доступу — ролі та мінімальні права, розділення обов’язків оператора й адміністратора, обов’язкова двофакторна автентифікація, порядок видачі й відкликання доступів, журнал дій зі зберіганням історії.
- Регламент реагування — рівні інцидентів, зона відповідальності кожного, порядок зупинки пари, увімкнення резервного маршруту ліквідності, шаблони оповіщень і критерій закриття інциденту.
- Інструкції для зміни — покрокові сценарії: ручне коригування курсу, розбір завислої заявки, звірка балансів і резервів, перевірка розходжень між внутрішнім обліком і провайдерами.
- Навчання зміни — прогін цих сценаріїв операторами на тестовому контурі під нашим наглядом, з чек-лістом приймання та розбором типових помилок.
Комплект оновлюється разом із системою: зміни конфігурацій і регламентів проходять через той самий контроль версій, що й код.
Кейс: як зросла пропускна здатність обміну
Що було до переробки
Заявки приймалися через веб-форму, а звірку надходжень і виплат оператор запускав вручну — при зростанні потоку черга розбиралася повільніше, ніж поповнювалася.
Будь-яка розсинхронізація підтверджень у мережі давала завислу заявку: клієнт бачив статус «в обробці», підтримка — тікет. У пікові години медіанний час сягав хвилин, а на оновленнях сервіс зупиняв приймання.
Що змінили
Обмін розбили на незалежні стадії: приймання заявки, резервування ліквідності, підтвердження вхідної транзакції, виплата, фінальний аудит.
У кожної стадії свій обробник з ідемпотентним ключем — повторний запуск не створює другу виплату, а зависла стадія йде в повтор з ескалацією в підтримку. Оркестрація контейнерів на Kubernetes дала оновлення без зупинки приймання заявок і передбачуване масштабування під піки.
Метрики до і після
| Метрика | До | Після |
|---|---|---|
| Медіанний час обробки заявки | 4-6 хвилин, у пік — більше 20 | 12-18 секунд |
| Частка ручних операцій | близько третини заявок через оператора | менше 2%, лише спірні випадки |
| Інциденти із завислими заявками | 8-12 на місяць | 0-1, закриваються автоповерненням |
| Простій при оновленні | до 40 хвилин | приймання заявок не зупиняється |
Перевірка адреси та лімітів тепер іде до резервування, тому відмови на етапі виплати майже зникли. Ідемпотентність зняла клас подвійних виплат, який раніше ловився лише звіркою в кінці дня.
Що робити, якщо обмін уже працює на розрізнених скриптах?
Розрізнені скрипти ламаються не від навантаження, а від стану: у кожного свій облік заявок, свій спосіб повторів і своє трактування статусу ордера.
Коли один падає на середині обміну, ніхто не знає, чи пішли кошти, тому звірка йде руками, а розходження випливає вже після скарги клієнта.
Починаємо з аудиту поточного рішення: виписуємо всі точки входу й виходу, відновлюємо фактичну логіку розрахунку курсу, лімітів і комісій, відзначаємо місця без ідемпотентності та без єдиного журналу операцій.
Як правило, перенесення логіки обміну стосується розрахункової частини та правил маршрутизації, а заново пишеться шар виконання — обробка статусів, повтори запитів, облік балансів і ключів доступу.
Міграція без простою будується на тіньовому режимі: нова система приймає ті самі заявки, рахує результат і пише журнал, але кошти не надсилає. Кілька днів її відповіді звіряються з тим, що роблять скрипти, — розходження розбираються до перемикання, а не після.
Далі йде поступовий перехід за напрямками: спочатку одна пара валют або частина потоку, потім інші. Зворотний перемикач на старий контур тримаємо до кінця спостереження, самі скрипти залишаємо в режимі читання, поки історія операцій і баланси не зійдуться.
У підсумку замість набору скриптів, де кожен крок тримається на пам’яті чергового, з’являється одна керована система з журналом і зрозумілим розбором спірних операцій.
Часті технічні питання: резерви, доступи, збої
Інженерні сумніви щодо автоматичного обмінника майже завжди одні й ті самі: поведінка під піковим навантаженням, затримки підтвердження, зберігання ключів і ліміти на операції. Нижче — короткі відповіді, повний розбір зі схемами йде в проєктній документації.
Резерви ліквідності ми рахуємо не «на око»: сервіс веде окремий облік за кожним активом і тримає буфер під добовий обіг, а ліміти на операції задаються політикою — на пару, на клієнта, на інтервал.
Це гасить аномальний потік, не заважаючи звичайним обмінам, а спостережуваність будується на метриках черги, частки відмов і розходження балансів.
Що відбувається при піковому навантаженні?
Заявки йдуть у чергу з пріоритетами, вхід обмежений за ключем доступу. Сплеск розтягує обробку, але не дає частково виконаних угод: обмін або проходить цілком, або знімається.
Як зберігаються ключі від гаманців?
Основний обсяг — у холодному зберіганні на апаратних модулях рівня Ledger, гарячий контур тримає лише операційний запас у межах ліміту. Підпис транзакцій винесено в окремий сервіс без доступу до решти даних.
Що якщо мережа не підтвердила транзакцію?
Обмін не вважається завершеним до потрібної кількості підтверджень, повтор іде із захистом від дублів. Якщо транзакція зависла довше вікна, вона потрапляє в окрему чергу й розбирається за журналом, без ручного пошуку.
Як ми дізнаємося про збої раніше за клієнта?
Алерти налаштовуються на відхилення курсу, простій черги та розходження балансів, а не лише на падіння сервісу. Черговий отримує сигнал до того, як проблема стане видною в заявках.
Обговоримо задачу: що потрібно для оцінки та плану робіт
Щоб оцінка проєкту обмінника була точною, а не «на око», нам потрібен зріз поточного стану: як обмін влаштований зараз і яким він має стати. Нижче — вихідні дані, які найчастіше визначають склад робіт і строки запуску. Якщо за якимось пунктом ясності немає, це теж відповідь: закладаємо його окремим етапом у план.
- Напрямки обміну та попит: які пари й коридори дають основний обіг, скільки заявок проходить за добу та в години пік.
- Рух коштів: як приймаються і видаються активи, чи бере участь людина в підтвердженні, де вузькі місця ручних операцій.
- Ліквідність: власний резерв, зовнішні постачальники, що відбувається з курсом і заявкою при відмові основного джерела.
- Ключі та зберігання: де лежать кошти, хто має доступ, як розділені ролі оператора, адміністратора та служби підтримки.
- Перевірки та правила: вимоги до ідентифікації клієнтів, контроль відмивання коштів, ліміти та стоп-листи.
- Інтеграції: з чим обмінник має обмінюватися даними — приймання платежів, аналітика, підтримка, бухгалтерія.
- Обмеження запуску: юрисдикція та вимоги регулятора, дата, до якої обмін має працювати, хто відповідає за приймання.
За цими даними ми повертаємося зі схемою потоків коштів, оцінкою, планом робіт за етапами та реальними строками запуску — з явно зазначеним, що робиться в першу чергу, а що можна винести в другу.
Опишіть задачу у вільній формі: навіть якщо частина відповідей поки під питанням, цього достатньо, щоб почати обговорення і запропонувати перший варіант архітектури.
