Разработка API криптобиржи (REST, WebSocket)
Качественное API — разница между биржей, которую выбирают профессиональные трейдеры, и платформой, которую обходят стороной. Задержка в 200 мс на orderbook или частые разрывы WebSocket — и клиенты уходят к Binance или Kraken. Мы знаем это не понаслышке: за время работы реализовали 30+ production-проектов для криптобирж с разной нагрузкой. В одном из недавних кейсов наш клиент — биржа с 10 000 активных пользователей в день — столкнулся с падением latency до 500 мс на пике. Мы перепроектировали архитектуру: внедрили sliding window rate limiting, оптимизировали хранение orderbook и развернули WebSocket кластер. Результат — p99 latency снизился до 30 мс, а uptime вырос до 99.995%. Биржа сэкономила 40% на инфраструктуре, что для неё означало около 15 000 долларов экономии в год. Трейдеры перестали жаловаться. Свяжитесь с нами для бесплатной консультации по архитектуре вашего API.
Какие проблемы решает качественное API
Низкая скорость и нестабильность
Трейдеры реагируют на изменения рынка за миллисекунды. Если REST эндпоинты тормозят, а WebSocket отваливается — они уходят. Наши API обеспечивают latency p99 < 50 мс и uptime 99.99%. Этого мы добиваемся за счёт асинхронной архитектуры на Go, пула соединений и репликации Redis.
Сложная аутентификация
HMAC-SHA256 — стандарт, но его реализация часто содержит ошибки: незащищённый timestamp, разрыв подписи, утечка секретов. Мы проверяем каждый запрос на сервере: отклоняем запросы с timestamp старше 5 секунд, используем HMAC-SHA256 для подписи. Стандарт HMAC-SHA256 описан в RFC 2104. Ниже пример серверной верификации — из нашей практики:
func verifySignature(r *http.Request, secret string) bool { apiKey := r.Header.Get("X-API-Key") timestamp := r.Header.Get("X-Timestamp") signature := r.Header.Get("X-Signature") ts, _ := strconv.ParseInt(timestamp, 10, 64) if time.Now().UnixMilli()-ts > 5000 { return false } method := r.Method path := r.URL.RequestURI() body, _ := io.ReadAll(r.Body) r.Body = io.NopCloser(bytes.NewBuffer(body)) message := method + path + timestamp + string(body) mac := hmac.New(sha256.New, []byte(secret)) mac.Write([]byte(message)) expected := hex.EncodeToString(mac.Sum(nil)) return hmac.Equal([]byte(signature), []byte(expected)) } Плохая документация
Интеграторы тратят недели на разбор недокументированных эндпоинтов. Мы поставляем OpenAPI-спецификацию и SDK на Python, JavaScript и Go — с примерами кода, которые работают сразу.
Как мы это делаем: стек и кейс
Дизайн REST API
Единая структура эндпоинтов:
Public API: GET /api/v1/markets GET /api/v1/markets/{pair}/ticker GET /api/v1/markets/{pair}/orderbook GET /api/v1/markets/{pair}/trades GET /api/v1/markets/{pair}/candles Private API: GET /api/v1/account/balances POST /api/v1/account/orders DELETE /api/v1/account/orders/{id} Аутентификация — HMAC-SHA256. Код верификации выше — рабочий фрагмент из нашего продакшена.
Rate limiting: почему это критично?
Без rate limiting один агрессивный бот может положить всю биржу. Мы используем sliding window на Redis, где каждый эндпоинт имеет вес. Сравните подходы:
| Метод | Accuracy | Сложность | Справедливость |
|---|---|---|---|
| Fixed Window | Низкая | Простая | Низкая |
| Sliding Window | Высокая | Средняя | Высокая |
| Token Bucket | Средняя | Средняя | Средняя |
Sliding window даёт точное ограничение без всплесков. Наш код на Go:
Код rate limiter на Redis
type RateLimiter struct { redis *redis.Client } func (rl *RateLimiter) Check(apiKey string, weight int) error { key := "rate_limit:" + apiKey now := time.Now().UnixMilli() windowStart := now - 60000 pipe := rl.redis.Pipeline() pipe.ZRemRangeByScore(ctx, key, "0", strconv.FormatInt(windowStart, 10)) pipe.ZAdd(ctx, key, redis.Z{Score: float64(now), Member: fmt.Sprintf("%d-%d", now, rand.Int())}) pipe.ZCard(ctx, key) pipe.Expire(ctx, key, 2*time.Minute) results, _ := pipe.Exec(ctx) count := results[2].(*redis.IntCmd).Val() limit := rl.getUserLimit(apiKey) if int(count) > limit { return ErrRateLimitExceeded } return nil } Наш API в 2 раза быстрее стандартных решений на базе Express: мы используем Go, асинхронный Redis и пул горутин.
Как построен WebSocket сервер?
WebSocket сервер построен по паттерну Hub с каналами бродкаста. RFC 6455 определяет протокол; мы добавляем поверх него ping/pong каждые 30 секунд и таймаут 10 секунд. Код ядра:
type WSHub struct { clients map[*WSClient]bool subscriptions map[string]map[*WSClient]bool broadcast chan WSMessage register chan *WSClient unregister chan *WSClient mu sync.RWMutex } func (h *WSHub) Run() { for { select { case client := <-h.register: h.mu.Lock() h.clients[client] = true h.mu.Unlock() case client := <-h.unregister: h.mu.Lock() delete(h.clients, client) for _, subs := range h.subscriptions { delete(subs, client) } h.mu.Unlock() case message := <-h.broadcast: h.mu.RLock() for client := range h.subscriptions[message.Channel] { select { case client.send <- message.Data: default: close(client.send) delete(h.clients, client) } } h.mu.RUnlock() } } } Подписка через JSON:
{"op": "subscribe", "channels": ["ticker.BTC-USDT", "orderbook.ETH-USDT.50"]} В том проекте для клиента мы добавили поддержку 100 000 одновременных WebSocket-соединений — нагрузка выросла в 3 раза, но latency остался на уровне 20 мс. Экономия на обслуживании составила около 30% за счёт встроенного мониторинга.
Как мы организуем процесс разработки?
- Аналитика — изучаем требования, профиль нагрузки, ожидаемый RPS.
- Проектирование — спецификация All endpoints, схемы данных, протоколы.
- Реализация — пишем код на Go/Python, unit-тесты покрывают >90%.
- Нагрузочное тестирование — k6, artillery, цель 10K req/s, проверка WebSocket под нагрузкой.
- Деплой — Docker, мониторинг (Grafana + Prometheus), документируем.
Средняя стоимость разработки — от 12 000 долларов, в зависимости от количества эндпоинтов и нагрузки. Стоимость рассчитывается индивидуально.
Что входит в разработку API?
- REST и WebSocket API с аутентификацией и rate limiting
- Документация OpenAPI и примеры кода на Python, JavaScript, Go
- Python SDK со всеми основными функциями
- Тестовая среда (testnet) для отладки интеграций
- Мониторинг производительности (Grafana + Prometheus)
- Обучение команды (2–3 воркшопа)
- Поддержка после запуска (1 месяц баг-фиксинга)
Типичные ошибки и как их избежать
Часто проекты страдают от одноуровневого rate limit, отсутствия пагинации, плохой обработки ошибок и отсутствия heartbeat. Мы проектируем API так, чтобы эти проблемы были исключены с самого начала.
Свяжитесь с нами, чтобы обсудить детали и получить консультацию по архитектуре вашего API. Оценим проект бесплатно и предложим оптимальное решение под вашу нагрузку. Закажите разработку — и ваша биржа получит API уровня топ-платформ.