Разработка системы автоматического обмена криптовалют под ключ

Разработка автоматического обменника: узкие места и отказы

Обменник уверенно работает на первых сотнях заявок, а ломается на росте. Первое узкое место — ручное подтверждение: пока оператор сверяет платёж и курс глазами, поток заявок растёт, время ответа уходит в десятки минут, и клиент уходит туда, где ответили быстрее.

Второе — рассинхрон курса. Витрина считает цену по одному источнику, исполнение идёт по другому, а между котировкой и сделкой проходит время. На спокойном рынке это доли процента, на волатильности — прямая потеря на разнице котировок, и она накапливается с каждой сделкой.

Третье — зависшие заявки. Обрыв связи с биржей, транзакция, застрявшая в сети, частичное исполнение — и заявка остаётся в статусе «в обработке». Клиент видит списание без зачисления, поддержка разбирает это вручную, часть средств заморожена, а доверие к сервису тает.

Автоматический обмен криптовалют терпит не отсутствие кода, а отсутствие логики восстановления. Поэтому разработка автоматического обменника начинается не с интерфейса, а с разбора узких мест обменника: как заявка получает однозначный статус и переживает перезапуск сервиса.

Дальше — как курс фиксируется на момент сделки и как система сама доводит операцию до конца или откатывает её без ручного вмешательства. Ниже разбираем, как это закрывается.

Что даёт автоматизация обмена: измеримые эффекты

Автоматический обменник — это не форма приёма заявки, а конвейер: ордер, проверка рисков, подбор ликвидности, исполнение и вывод по каждому активу проходят без оператора. Время обработки заявки перестаёт зависеть от смены дежурного и определяется глубиной очереди и числом подтверждений в сети — на ликвидных парах это секунды, на редких активах предел задаёт сама цепочка вроде Bitcoin, а не наша сторона. Мы снимаем медиану и 95-й перцентиль по каждой паре отдельно, поэтому узкое место видно до того, как его заметит клиент.

Что меняется в измеримых величинах:

• доля ручных операций падает с «каждая заявка» до единичных разборов — только спорные и крупные суммы, требующие ручного подтверждения;
• доступность сервиса уходит в район, где плановые работы и перезапуск узла не прерывают приём заявок;
• уходит целый класс отказов: потеря заявки при обрыве связи, двойное исполнение при повторной отправке, зависшая транзакция без статуса;
• расхождение курса между внутренним расчётом и источником ликвидности закрывается автоматически, а не ручной правкой.

Отказоустойчивость обменника держится на трёх вещах: идемпотентность операций, чтобы повторный запрос не создал вторую сделку; разнесение горячего контура вывода и холодного хранения; автоматическая пауза по паре при расхождении баланса или курса выше заданного порога. Каждое действие пишется в журнал с идентификатором заявки, поэтому восстановление после сбоя — это проигрывание журнала, а не разбор переписки.

Дальше — как это устроено в конкретной архитектуре и какие проверки закрывают риски на старте.

Форматы запуска: готовое ядро, свой модуль, гибрид

Выбор формата запуска определяется не размером бизнеса, а тем, кто отвечает за маршрутизацию заявок и насколько нестандартна логика сопоставления. Готовое ядро обменника закрывает стандартный поток: приём заявки, резервирование ликвидности, исполнение, вывод. Собственный модуль сопоставления берут там, где правило ценообразования нельзя выразить конфигурацией — например, когда курс зависит одновременно от объёма, источника ликвидности и уровня резерва.

Гибридная схема обмена чаще всего выигрывает: ядро отвечает за учёт и безопасность средств, а маршрутизация заявок и правила сопоставления живут в отдельном сервисе, который общается с ядром через очередь событий. Ниже — когда какой формат подходит и чем за него платят.

Что бы ни выбрали, контракт на размещение заявок фиксируем до начала работ — иначе смена формата на середине проекта превращается в переписывание ядра.

Этапы внедрения: от аудита потока до передачи в работу

Каждая следующая итерация опирается на артефакт предыдущей: без схемы маршрутизации нельзя настраивать резервы, без настроенных резервов — воспроизводимо проверять сценарии. Ниже — последовательность работ, в которой мы ведём проект автоматического обменника.

1. Аудит потока заявок. Разбираем текущую картину: востребованные направления, как приходят заявки, где теряются, какой объём система держит в пиковые часы. На выходе — перечень узких мест с оценкой нагрузки.
2. Схема маршрутизации. Фиксируем путь заявки от входа до исполнения: правила выбора направления, приоритеты, поведение при расхождении котировок между площадками. Схему согласуем до кода — спорные места всплывают на бумаге, а не в работе.
3. Настройка резервов. Определяем, сколько ликвидности держать на каждом направлении, как выравнивать балансы и что делать при просадке. Пороги, после которых обменник останавливает приём заявок вместо исполнения в убыток, описываем заранее.
4. Проверка сценариев. Прогоняем систему на исторических и синтетических данных: резкие движения рынка, частичное исполнение, недоступность внешней площадки. Каждый сценарий завершается предсказуемо — возвратом средств или корректным отказом.
5. Регламенты и мониторинг. Пишем инструкции для операторов: как читать панель мониторинга, что делать при срабатывании оповещения, как вручную остановить направление. Оповещения ставим на отклонение баланса и рост времени исполнения.
6. Передача в эксплуатацию. Разворачиваем на вашей инфраструктуре, прогоняем контрольный обмен, передаём доступы, схему и документацию. Остаёмся на связи в первые недели — правки идут по реальному потоку заявок.

Конфигурации, регламенты и документация обменника

После запуска обменника у заказчика остаётся полный комплект материалов, по которым систему можно сопровождать и развивать без нас. Мы передаём его по описи, с версионированием и разметкой «что меняется при обновлении ядра» — чтобы новый инженер или подрядчик не разбирал поведение обменника методом проб. Ниже — что именно входит в комплект.

• Документация обменника — архитектурная схема, модель данных, жизненный цикл заявки от создания до финального статуса, порядок обновлений и откат на предыдущую сборку.
• Схемы интеграций — потоки между ядром обменника, источниками курсов, кассовым модулем и платёжными рельсами, с точками отказа и описанным поведением при недоступности каждого контура.
• Конфигурации — параметры по каждой паре: лимиты, шаг округления, пороги допустимого расхождения курса, уровни комиссий. У каждого значения указано, почему выбрано именно оно и на что влияет при изменении.
• Политики доступа — роли и минимальные права, разделение обязанностей оператора и администратора, обязательная двухфакторная аутентификация, порядок выдачи и отзыва доступов, журнал действий с хранением истории.
• Регламент реагирования — уровни инцидентов, зона ответственности каждого, порядок остановки пары, включение резервного маршрута ликвидности, шаблоны оповещений и критерий закрытия инцидента.
• Инструкции для смены — пошаговые сценарии: ручная корректировка курса, разбор зависшей заявки, сверка балансов и резервов, проверка расхождений между внутренним учётом и провайдерами.
• Обучение смены — прогон этих сценариев операторами на тестовом контуре под нашим наблюдением, с чек-листом приёмки и разбором типовых ошибок.

Комплект обновляется вместе с системой: изменения конфигураций и регламентов проходят через тот же контроль версий, что и код.

Кейс: как выросла пропускная способность обмена

Что было до переработки

Заявки принимались через веб-форму, а сверку поступлений и выплат оператор запускал вручную — при росте потока очередь разбиралась медленнее, чем пополнялась. Любая рассинхронизация подтверждений в сети давала зависшую заявку: клиент видел статус «в обработке», поддержка — тикет. В пиковые часы медианное время доходило до минут, а на обновлениях сервис останавливал приём.

Что изменили

Обмен разбили на независимые стадии: приём заявки, резервирование ликвидности, подтверждение входящей транзакции, выплата, финальный аудит. У каждой стадии свой обработчик с идемпотентным ключом — повторный запуск не создаёт вторую выплату, а зависшая стадия уходит в повтор с эскалацией в поддержку. Оркестрация контейнеров на Kubernetes дала обновление без остановки приёма заявок и предсказуемое масштабирование под пики.

Метрики до и после

Проверка адреса и лимитов теперь идёт до резервирования, поэтому отказы на этапе выплаты почти исчезли. Идемпотентность сняла класс двойных выплат, который раньше ловился только сверкой в конце дня.

Что делать, если обмен уже работает на разрозненных скриптах?

Разрозненные скрипты ломаются не от нагрузки, а от состояния: у каждого свой учёт заявок, свой способ повторов и своя трактовка статуса ордера. Когда один падает на середине обмена, никто не знает, ушли ли средства, поэтому сверка идёт руками, а расхождение всплывает уже после жалобы клиента.

Начинаем с аудита текущего решения: выписываем все точки входа и выхода, восстанавливаем фактическую логику расчёта курса, лимитов и комиссий, отмечаем места без идемпотентности и без единого журнала операций. Как правило, перенос логики обмена касается расчётной части и правил маршрутизации, а заново пишется слой исполнения — обработка статусов, повторы запросов, учёт балансов и ключей доступа.

Миграция без простоя строится на теневом режиме: новая система принимает те же заявки, считает результат и пишет журнал, но средства не отправляет. Несколько дней её ответы сверяются с тем, что делают скрипты, — расхождения разбираются до переключения, а не после.

Дальше идёт постепенный переход по направлениям: сначала одна пара валют или часть потока, затем остальные. Обратный переключатель на старый контур держим до конца наблюдения, сами скрипты оставляем в режиме чтения, пока история операций и балансы не сойдутся.

В итоге вместо набора скриптов, где каждый шаг держится на памяти дежурного, появляется одна управляемая система с журналом и понятным разбором спорных операций.

Частые технические вопросы: резервы, доступы, сбои

Инженерные сомнения по автоматическому обменнику почти всегда одни и те же: поведение под пиковой нагрузкой, задержки подтверждения, хранение ключей и лимиты на операции. Ниже — короткие ответы, полный разбор со схемами идёт в проектной документации.

Резервы ликвидности мы считаем не «на глаз»: сервис ведёт отдельный учёт по каждому активу и держит буфер под суточный оборот, а лимиты на операции задаются политикой — на пару, на клиента, на интервал. Это гасит аномальный поток, не мешая обычным обменам, а наблюдаемость строится на метриках очереди, доли отказов и расхождения балансов.

Как хранятся ключи от кошельков?

Основной объём — в холодном хранении на аппаратных модулях уровня Ledger, горячий контур держит только операционный запас в пределах лимита. Подпись транзакций вынесена в отдельный сервис без доступа к остальным данным.

Что если сеть не подтвердила транзакцию?

Обмен не считается завершённым до нужного числа подтверждений, повтор идёт с защитой от дублей. Если транзакция зависла дольше окна, она попадает в отдельную очередь и разбирается по журналу, без ручного поиска.