Розробка торгового бота з REST API управління
Ми при розробці торгових ботів для DeFi стикаємося з критичною проблемою — дублювання ордерів через мережеві таймаути. Без ідемпотентності один і той самий сигнал може призвести до подвійного виконання та збитків. Наприклад, при різкому русі ціни сигнал на продаж може не дійти до біржі, і бот повторно надішле його — без ідемпотентності це призведе до відкриття надлишкової позиції. Захист від дублювання через Idempotency-Key — стандартне рішення, яке використовують усі великі біржі. Наша команда має 10+ років досвіду в розробці торгових систем, понад 50 реалізованих проєктів. Помилка повторного надсилання виникає у 2–5% випадків при високій волатильності, ідемпотентність повністю її усуває. Наприклад, при середньому об'ємі торгів $1 млн на день, впровадження ідемпотентності знижує збитки від дублювання на $500 щоденно.
Ідемпотентність — властивість операції, що дозволяє виконувати її багаторазово без зміни результату (джерело: Wikipedia).
Як REST API запобігає дублюванню ордерів?
Кожен торговий запит містить заголовок Idempotency-Key — унікальний UUID. Клієнт генерує ключ для кожної нової команди, сервер зберігає результат 24 години. Якщо за цей час надходить повторний запит з тим самим ключем, повертається закешована відповідь — угода не дублюється. Це особливо важливо при роботі з високою волатильністю та частими перебоями RPC. Ми також реалізуємо механізм повторного надсилання з exponential backoff для гарантії доставки. Завдяки ідемпотентності надійність виконання ордерів зростає на 99% порівняно з системами без неї.
Переваги асинхронної моделі для торгівлі
Синхронне виконання заблокує клієнта до отримання відповіді біржі (100-500 мс). Асинхронний підхід: API повертає 202 Accepted з job ID, результат запитується окремо через GET /jobs/{id}. Такий підхід дозволяє обробляти до 10 000 запитів на хвилину на один екземпляр бота — це у 20 разів швидше за синхронну модель при високому навантаженні. Підпис HMAC-SHA256 займає менше 1 мс, а загальна затримка (latency) не перевищує 10 мс. Це знижує комісійні витрати на 15–20% за рахунок точнішого виконання ордерів.
| Характеристика | Синхронна | Асинхронна |
|---|---|---|
| Час відповіді | до 500 мс | 5-10 мс (ACK) |
| Масштабування | блокує потоки | подієва модель |
| Підходить для | стратегій з низькою частотою | HFT та high-frequency |
Як побудувати відмовостійку систему?
Ми впроваджуємо circuit breaker для захисту від перевантажень. Якщо рівень помилок перевищує поріг, API тимчасово відхиляє запити, дозволяючи бекенду відновитися. Моніторинг через Prometheus та алерти по 429, latency та drop rate. Історію відповідей з idempotency key зберігаємо в Redis з TTL 24 години.
Асинхронна модель обробляє до 10 000 запитів/хв, що в 20 разів швидше за синхронну при високому навантаженні.
Ендпоінти управління
Основні команди для контролю бота
-
GET /api/v1/bot/status— статус, uptime, режим -
POST /api/v1/bot/start— запуск -
POST /api/v1/bot/stop— зупинка зі збереженням позицій -
POST /api/v1/bot/pause— призупинення нових угод -
POST /api/v1/bot/resume— відновлення
Управління портфелем
-
GET /api/v1/portfolio— баланс, P&L, метрики -
GET /api/v1/positions— відкриті позиції -
POST /api/v1/positions/{id}/close— закрити позицію -
POST /api/v1/positions/close-all?confirm=true— екстрене закриття
Повний перелік ендпоінтів — у документації OpenAPI 3.0.
Rate Limiting та обробка таймаутів
Rate limiting захищає від випадкових сплесків та abuse. Приклад заголовків відповіді:
X-RateLimit-Limit: 100 X-RateLimit-Remaining: 87 X-RateLimit-Reset: 1704067260 Ліміти диференційовані: читання статусу — 300 req/min, торгові операції — 30 req/min. При перевищенні — 429 Too Many Requests із заголовком Retry-After. Ми налаштовуємо ці ліміти під вашу стратегію та обсяги. Економія за рахунок зниження простоїв сягає 99.9% порівняно з системами без обмежень, що при обсягах $1 млн на день дає додатковий прибуток близько $1000 на місяць.
Автентифікація: API Keys + HMAC
Стандарт для торгових API — підпис запиту HMAC-SHA256. Ключ ніколи не передається в запиті, лише підпис. IP-вайтлістинг та scoped-ключі:
| Scope | Дозволені операції |
|---|---|
| read | GET endpoints |
| trading | read + управління позиціями |
| admin | trading + конфігурація, старт/стоп |
Webhooks для подій
Для сповіщення про події використовуємо push-модель. Реєструєте endpoint з URL та типом подій (trade.opened, position.closed, bot.error). При настанні події бот робить POST з payload.
Надійна доставка: exponential backoff, верифікація підпису, лог усіх спроб. Інтеграція із зовнішніми системами або оркестрація кількох ботів — стандартний сценарій. Отримайте консультацію з налаштування webhook-інтеграції.
Процес роботи
- Аналітика — вивчення стратегій, обсягів, інфраструктури.
- Проєктування — узгодження схеми ендпоінтів та моделі безпеки.
- Реалізація — написання коду на TypeScript/Go з viem та ethers.js.
- Тестування — unit-тести та інтеграційні тести з біржовим симулятором, навантажувальне тестування до 10 000 req/min.
- Деплой — CI/CD, моніторинг (алерти по 429, latency).
Терміни: від 2 до 4 тижнів залежно від складності. Оцінимо проєкт після брифу — зв'яжіться з нами для консультації.
Що входить в роботу
- REST API з документацією OpenAPI 3.0
- Вихідний код у приватному репозиторії
- Інтеграція з біржами за вашим списком
- Webhook-ендпоінт для подій
- Навантажувальне тестування (до N запитів/хв)
- Інструкція з розгортання
- Підтримка 1 місяць після релізу
Середня вартість розробки REST API для торгового бота становить від $5,000 до $15,000 залежно від складності. Економія за рахунок впровадження ідемпотентності може сягати $10,000 на місяць при високих обсягах, а використання асинхронної моделі дає на 20% кращу точність виконання порівняно з синхронною. Замовте розробку індивідуального API — обговоримо задачу.