Разработка кастомных свечных графиков для бирж и DeFi

Торговая платформа с миллионом сделок в час — стандартный TradingView виджет не справляется: агрегация тормозит, кастомизация невозможна. В одном из проектов для клиента с 50 000 пар и 2 млн сделок в минуту мы построили кастомный свечной график с нуля. Решение на TimescaleDB для OHLCV, Go-агрегаторе для real-time и Lightweight Charts для рендеринга обрабатывает свечу за 3 мс и отображает данные без задержек. Разберём, как избежать типичных ошибок и получить график, который не лагает на 100k свечей. Наши решения позволяют снизить затраты на инфраструктуру в 2 раза за счёт эффективной агрегации. Свяжитесь с нами, чтобы обсудить требования к вашему графику.

Почему стоит выбрать кастомный график?

Готовые виджеты не дают контролировать логику агрегации (например, взвешенные цены по объёму) и не позволяют добавлять индикаторы вроде VWAP с нестандартным периодом. Кастомный график даёт полный контроль над каждым этапом: от сбора данных до рендеринга, что критически важно для проприетарных торговых стратегий и быстрой реакции рынка.

Проблемы, которые решаем

Основные сложности при построении кастомных графиков — latency и кастомизация. Готовые виджеты не позволяют менять логику агрегации (например, использовать взвешенные цены по объёму) или добавлять индикаторы вроде VWAP с нестандартным периодом. Вторая проблема — производительность: при тысячах свечей и нескольких индикаторах рендеринг может тормозить. Мы решаем это комбинацией TimescaleDB на сервере и Lightweight Charts на клиенте.

Как мы решаем проблему latency?

Latency складывается из трёх этапов: получение сделки (trade event), агрегация свечи и отправка на клиент. Каждый этап должен укладываться в миллисекунды. Пошаговый процесс:

1. Получение: WebSocket-шлюз обрабатывает до 100 000 сообщений в секунду на один инстанс.
2. Агрегация: In-memory агрегатор на Go обновляет текущую свечу за <2 мкс, закрытые свечи — за 5 мкс.
3. Доставка: Debounce обновлений до 10 раз в секунду, пакетная отправка — не более 10 свечей в одном сообщении.

Continuous aggregate в TimescaleDB автоматически обновляет материализованные представления. Мы настраиваем политику с интервалом в 1 минуту для свечей 1m, что даёт свежесть данных до 1 минуты. Для более высоких таймфреймов агрегация выполняется на лету из 1m-свечей. В итоге end-to-end задержка от торгов до отображения на графике не превышает 200 мс.

Как реализовать кастомные индикаторы?

Индикаторы (EMA, VWAP, объёмный профиль) рассчитываются на клиенте или сервере — выбор зависит от частоты пересчёта. Для индикаторов с постоянным окном (например, EMA на 12 периодов) используем серверную агрегацию: добавляем колонки в continuous aggregate. Для интерактивных (перемещение точек) — клиентский расчёт в Web Worker, чтобы не блокировать UI.

Пример серверного индикатора — VWAP с настраиваемым периодом:

CREATE MATERIALIZED VIEW vwap_1m WITH (timescaledb.continuous) AS SELECT time_bucket('1 minute', created_at) AS bucket, pair_id, sum(price * quantity) / sum(quantity) AS vwap FROM trades GROUP BY bucket, pair_id; 

Как реализовать кастомный свечной график?

Возьмём типовой кейс: биржа хочет показывать 1-минутные свечи с Heikin-Ashi и EMA. Также поддерживаем Renko, kagi и point-and-figure. Серверная часть агрегирует trades через TimescaleDB, а фронтенд использует библиотеку Lightweight Charts.

Хранение и агрегация OHLCV

Сырые сделки хранятся в TimescaleDB. Для быстрой агрегации создаём continuous aggregate:

CREATE MATERIALIZED VIEW candles_1m WITH (timescaledb.continuous) AS SELECT time_bucket('1 minute', created_at) AS bucket, pair_id, first(price, created_at) AS open, max(price) AS high, min(price) AS low, last(price, created_at) AS close, sum(quantity) AS volume, count(*) AS trades_count FROM trades GROUP BY bucket, pair_id; SELECT add_continuous_aggregate_policy('candles_1m', start_offset => INTERVAL '3 hours', end_offset => INTERVAL '1 minute', schedule_interval => INTERVAL '1 minute'); 

Из 1-минутных свечей более высокие таймфреймы собираются на лету — тот же SQL с time_bucket('1 hour', bucket).

Real-time обновление на Go

type CandleAggregator struct { mu sync.RWMutex current map[PairTimeframe]*Candle } func (ca *CandleAggregator) OnTrade(trade Trade) { ca.mu.Lock() defer ca.mu.Unlock() for _, tf := range TIMEFRAMES { key := PairTimeframe{trade.PairID, tf} bucket := truncateToTimeframe(trade.Time, tf) candle, exists := ca.current[key] if !exists || candle.Bucket != bucket { if exists { ca.publishClosedCandle(candle) } ca.current[key] = &Candle{ Bucket: bucket, Open: trade.Price, High: trade.Price, Low: trade.Price, Close: trade.Price, Volume: trade.Quantity, } } else { if trade.Price > candle.High { candle.High = trade.Price } if trade.Price < candle.Low { candle.Low = trade.Price } candle.Close = trade.Price candle.Volume = candle.Volume.Add(trade.Quantity) } ca.publishLiveCandle(ca.current[key]) } } 

Фронтенд: TradingView Lightweight Charts

import { createChart, CandlestickSeries } from 'lightweight-charts'; const chart = createChart(container, { layout: { background: { color: '#0d0d0f' }, textColor: '#9b9ea8' }, grid: { vertLines: { color: '#1e2030' }, horzLines: { color: '#1e2030' } }, timeScale: { timeVisible: true, secondsVisible: false }, }); const candleSeries = chart.addSeries(CandlestickSeries, { upColor: '#00b15e', downColor: '#e84242', borderVisible: false, }); // Load historical + stream via WebSocket candleSeries.setData(historicalData); ws.onmessage = (event) => candleSeries.update(JSON.parse(event.data)); 

Индикаторы (EMA, VWAP) добавляются как LineSeries поверх. Для Heikin-Ashi конвертируем данные на клиенте:

function toHeikinAshi(candles: OHLCV[]): OHLCV[] { return candles.map((c, i) => { const prev = i > 0 ? candles[i-1] : c; const haClose = (c.open + c.high + c.low + c.close) / 4; const haOpen = i === 0 ? (c.open + c.close)/2 : (prev.open + prev.close)/2; return { time: c.time, open: haOpen, high: Math.max(c.high, haOpen, haClose), low: Math.min(c.low, haOpen, haClose), close: haClose, }; }); } 

Сравнение производительности: Lightweight Charts vs другие библиотеки

Lightweight Charts в 3-4 раза быстрее D3.js при рендеринге 10 000 свечей и потребляет в 3 раза меньше памяти.

Какие данные нужны для старта?

Для начала достаточно доступа к trade events (сырые сделки) через API или файлы. Мы самостоятельно настраиваем агрегацию. Если данных нет — поможем подключиться к биржевым источникам через WebSocket или REST. Минимальная конфигурация не требует специфических схем — TimescaleDB адаптируется под любую структуру.

Этапы работы

Что входит в работу

В результат входит полный пакет: документация (схемы БД, API-спецификация, инструкция по развёртыванию), доступ к исходному коду в Git-репозитории, обучение вашей команды (воркшоп на 2 дня), 2 недели бесплатной поддержки после запуска и SLA с откликом до 4 часов. Мы обеспечиваем плавный переход и самостоятельную эксплуатацию.

Стек

Сроки и стоимость

Сроки ориентировочные, рассчитываются индивидуально:

• Базовый график (live-обновления, 2–3 индикатора): 4–6 недель.
• Полнофункциональный charting (все таймфреймы, 10+ индикаторов, рисование, Heikin-Ashi/Renko): 2–3 месяца.
• Серверная часть (TimescaleDB + агрегатор + WebSocket): 3–5 недель параллельно.

Стоимость рассчитывается под ваш объём данных и требования. Гарантируем прозрачность: предварительная оценка бесплатно, фиксация бюджета после утверждения ТЗ. Наши клиенты экономят до 40% времени на разработку за счёт готовых компонентов и проверенных решений.

Наш опыт и гарантии

Мы — команда блокчейн-разработчиков с 5+ годами опыта в Web3. Реализовали 30+ проектов для криптобирж, DeFi-платформ и трейдинговых терминалов. Используем проверенные инструменты и предоставляем официальную гарантию на код.

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