Binance — найчастіший запит. У них два stream варіанти:

• btcusdt@depth — оновлення кожні 100ms або 1000ms (параметр @depth@100ms)
• btcusdt@depth20 — топ-20 рівнів кожні 100ms (без інкрементальних оновлень, завжди повний)

Для повного стакану з застосуванням патчів:

async def maintain_binance_orderbook(symbol: str): ob = OrderBook() buffer = [] # буфер оновлень до отримання snapshot async def handle_ws_message(msg): data = json.loads(msg) # Накопичуємо оновлення ПОКИ не отримаємо snapshot if ob.last_update_id == 0: buffer.append(data) return # Binance: оновлення валідне якщо U <= lastUpdateId+1 <= u if data['U'] <= ob.last_update_id + 1 <= data['u']: ob.apply_update(data['b'], data['a'], data['u']) # Запускаємо WS ws_task = asyncio.create_task(connect_ws( f"wss://stream.binance.com:9443/ws/{symbol.lower()}@depth@100ms", handle_ws_message )) # Отримуємо snapshot (трохи чекаємо щоб буфер накопичився) await asyncio.sleep(0.5) async with aiohttp.ClientSession() as session: async with session.get( f"https://api.binance.com/api/v3/depth", params={"symbol": symbol.upper(), "limit": 1000} ) as resp: snapshot = await resp.json() # Ініціалізуємо стакан із snapshot for price, qty in snapshot['bids']: ob.bids[float(price)] = float(qty) for price, qty in snapshot['asks']: ob.asks[float(price)] = float(qty) ob.last_update_id = snapshot['lastUpdateId'] # Застосовуємо буферизовані оновлення for update in buffer: if update['u'] > ob.last_update_id: ob.apply_update(update['b'], update['a'], update['u']) await ws_task 

Критичний момент: якщо пропущено update (gap в U → u послідовності) — стакан розсинхронізовано. Потрібна логіка ресинхронізації: детектувати gap та переініціалізувати з нового snapshot.

Кейс: агрегація Binance та Bybit для арбітражу

Для крос-біржового арбітражу необхідно підтримувати книги заявок кількох бірж паралельно. Ось приклад агрегатора, який знаходить найкращу ціну:

EXCHANGES = { "binance": BinanceOrderBook, "bybit": BybitOrderBook, "okx": OKXOrderBook, } async def run_aggregator(symbol: str): books = {name: cls(symbol) for name, cls in EXCHANGES.items()} tasks = [book.run() for book in books.values()] await asyncio.gather(*tasks) def get_best_price_across_exchanges(books: dict[str, OrderBook]) -> dict: best_bids = [(name, *ob.best_bid) for name, ob in books.items() if ob.best_bid] best_asks = [(name, *ob.best_ask) for name, ob in books.items() if ob.best_ask] best_bids.sort(key=lambda x: x[1], reverse=True) best_asks.sort(key=lambda x: x[1]) return { "best_bid": {"exchange": best_bids[0][0], "price": best_bids[0][1], "qty": best_bids[0][2]}, "best_ask": {"exchange": best_asks[0][0], "price": best_asks[0][1], "qty": best_asks[0][2]}, "spread": best_asks[0][1] - best_bids[0][1] } 

Агрегація в реальному часі дозволяє бачити найкращу ціну на купівлю та продаж по всіх біржах. Це основа для арбітражних стратегій та побудови unified order book.

Зберігання даних: TimescaleDB vs файлове

Для backtesting або аудиту — зберігання потоку оновлень, а не тільки знімків. L2 order book updates — це великий обсяг: для BTC/USDT на Binance ~100MB/год нестиснутих даних (для 10 пар ~1GB/год).

Ми рекомендуємо використовувати TimescaleDB для довгострокового зберігання та Parquet для аналітики. За необхідності інтегруємо потік в Kafka для downstream-систем.

# Запис у бінарний формат через msgpack import msgpack, lz4.frame def serialize_update(update: dict) -> bytes: packed = msgpack.packb(update, use_bin_type=True) return lz4.frame.compress(packed) # TimescaleDB для time-series зберігання # Гіпертаблиця автоматично партиціонує за часом CREATE TABLE ob_updates ( time TIMESTAMPTZ NOT NULL, exchange TEXT NOT NULL, symbol TEXT NOT NULL, side CHAR(1) NOT NULL, -- 'b' або 'a' price NUMERIC NOT NULL, quantity NUMERIC NOT NULL ); SELECT create_hypertable('ob_updates', 'time'); 

Що входить у роботу?

При замовленні системи збору order book ви отримуєте:

• Архітектурне рішення з вибором протоколів та стратегії ресинхронізації
• Вихідний код на Python з asyncio та документацію по розгортанню
• Дашборди Grafana для моніторингу затримок та помилок
• Гарантію стабільності 99.9% та підтримку протягом двох тижнів після впровадження

Розробка системи під ключ для однієї біржі стартує від $2000, для трьох — від $5000. Термін виконання — 2-4 тижні. Оцінка проекту безкоштовно — зв'яжіться з нами для обговорення.

Типові помилки при зборі order book

• Ігнорування sequence ID та відсутність ресинхронізації після gap
• Використання REST polling замість WebSocket (призводить до затримок та лімітів)
• Неправильний порядок: спочатку snapshot, потім підписка на оновлення
• Відсутність буферизації оновлень до отримання snapshot (втрачаються перші пакети)
• Некоректна обробка reconnect з експоненційним backoff

Замовте розробку системи збору order book з гарантією стабільності та низькою латентністю. Наш досвід у high-frequency trading дозволяє створювати рішення, які не втрачають дані та не розсинхронізуються навіть при пікових навантаженнях.