The order book is the exchange. Build the matching engine that handles real volume.

Every matching engine bug is a financial bug. Price-time priority violations, race conditions, and phantom fills destroy trader trust in minutes.

A matching engine is the financial source of truth for your exchange. When an order enters the system, the engine must determine in microseconds whether it crosses, partially fills, or rests in the book — and it must do this atomically, in strict price-time priority, with no race conditions under concurrent load. The execution journal is the audit trail that proves every fill is correct. A matching engine that produces incorrect fills is not an engineering problem — it is a legal and financial problem. PROPELOO designs matching engines around correctness first: deterministic order processing, complete audit journaling, and correctness tests that run on every build before latency is ever measured.

What a production matching engine actually contains.

The order book is one data structure inside a larger trading infrastructure system.

System Layers

• Order Intake Layer: FIX gateway, REST order API, WebSocket order stream, order validation, rate limiting, client authentication
• Risk Pre-check Layer: Pre-trade risk: margin check, position limits, order size limits, rate limits, kill switch
• Matching Core: Price-time priority order book, FIFO queue per price level, order types (market, limit, stop, IOC, FOK), atomic matching loop
• Execution & Settlement Layer: Execution journal, trade confirmation, fill notification, position update, ledger credit/debit, fee calculation
• Market Data Layer: Order book snapshots, incremental depth updates, trade tape, WebSocket broadcast, historical tick storage

Core Technical Capabilities

• Order Book Engine

  Price-time priority order book with O(1) best bid/ask lookup, O(log N) order insertion, concurrent access via lock-free data structures or single-threaded event loop. Supports limit, market, IOC, FOK, stop-limit and trailing stop orders.

• Pre-Trade Risk Engine

  Synchronous risk checks in the order path: margin sufficiency, position limit enforcement, order size caps, self-trade prevention, kill switch activation. Risk checks are in-process — no network round trip — to stay in the execution path.

• Execution Journal & Audit Trail

  Append-only execution journal: every order state transition, match event, fill, cancellation and rejection is durably logged with microsecond timestamp before the response is sent. The journal is the ground truth for dispute resolution and regulatory reporting.

• Market Data Distribution

  Real-time order book depth (L2/L3), trade tape, best bid/ask feed and OHLCV aggregation. WebSocket push to connected clients with sequence numbers for gap detection and snapshot-plus-delta recovery.

• Position & Ledger Updates

  Synchronous position and ledger updates on each fill — no eventual consistency on financial state. Maker/taker fee calculation, fee ledger credits, exchange revenue tracking and daily settlement reporting.

• Admin & Circuit Breakers

  Market-wide halt, per-symbol halt, per-account kill switch, order book drain, price band controls and market-maker spread obligations. All admin actions journaled and auditable.

How we approach matching engine architecture.

A matching engine has two correctness requirements that must not be violated: price-time priority and atomicity. Everything else — throughput, latency, features — is secondary to these invariants.

• Correctness before throughput

  The order in which you optimize a matching engine matters. First: prove the matching logic is correct under all order type combinations and edge cases. Second: prove it is correct under concurrent load. Third: measure and optimize throughput. Teams that build for throughput first create matching engines that are fast and wrong — which is worse than slow and correct.

  Axiom: CORRECT FIRST, FAST SECOND

• The execution journal is the system

  A matching engine without a complete, durable execution journal is not a trading system — it is a simulation. Every order event must be persisted before the acknowledgement is sent. If the engine crashes between match and journal write, fills are lost. We design the journal write as part of the critical path, not an afterthought.

  Axiom: JOURNAL IS GROUND TRUTH

• Risk checks belong inside the matching loop

  Pre-trade risk that requires a network call to an external service creates latency and a failure mode. Risk checks — margin, position limits, kill switch state — must be in-process, reading from in-memory state that is kept consistent with the matching engine. The risk engine and matching engine are the same process.

  Axiom: IN-PROCESS RISK ONLY

• Market data is an output, not a feature

  WebSocket market data feeds are a critical output of the matching engine, not a secondary feature. Traders making decisions on stale or incorrect depth data will have bad fills and will blame the exchange. The market data pipeline must be tested for correctness, sequenced for gap detection and load tested for the number of concurrent subscribers you expect at peak.

  Axiom: DATA QUALITY = TRADER TRUST

The decisions that define matching engine architecture.

These choices determine correctness, throughput, and the cost of operating the system at scale.

• Single-threaded event loop vs multi-threaded with locking?

  Impact: Single-threaded event loop is the correct default for most exchanges. It eliminates lock contention, makes correctness reasoning tractable, and delivers sub-millisecond latency for most throughput requirements. Multi-threading is justified only when single-book throughput exceeds single-core capacity.

  • Single-threaded event loop (LMAX Disruptor pattern) — no locks, deterministic order processing, bounded latency, limited to one CPU core per book
  • Multi-threaded with per-price-level locking — higher theoretical throughput, significant complexity, deadlock risk
  • Actor model (one actor per order book) — concurrent per-symbol, isolated state, message-passing overhead
  • Lock-free data structures — maximum concurrency, extremely complex correctness proofs

• In-memory order book vs database-backed?

  Impact: Always in-memory with a synchronous append-only journal and periodic snapshotting. Database-backed order books cannot achieve the latency requirements of any live exchange.

  • Fully in-memory order book — microsecond matching, requires durability layer (journal + snapshot)
  • Database-backed order book — simple recovery, 100x–1000x slower per operation
  • Hybrid — in-memory matching, synchronous journal write, periodic snapshot

• WebSocket market data: fan-out architecture?

  Impact: Redis Pub/Sub for exchanges below 10,000 concurrent WebSocket subscribers. Kafka-based distribution for exchanges where market data volume justifies the operational overhead.

  • In-process WebSocket broadcast — minimal latency, limited horizontal scaling
  • Redis Pub/Sub fan-out — decoupled, easy horizontal scaling, adds ~1ms latency
  • Kafka-based distribution — highest throughput, highest operational complexity
  • CDN-edge delivery (Cloudflare Durable Objects) — global low latency, limited depth

• FIX gateway vs REST-only?

  Impact: REST + WebSocket for retail-first exchanges. Add FIX when institutional market makers are required for liquidity — they will not integrate without it.

  • REST + WebSocket — sufficient for retail exchanges, lower integration cost
  • FIX 4.2/4.4 gateway — required for institutional participants, market makers, algorithmic traders
  • Both REST and FIX — maximum addressable market, higher implementation cost

• How to handle partial fills and order state?

  Impact: Immutable order records with an append-only execution journal. This gives a complete audit trail, simplifies recovery after crash, and eliminates update races.

  • Immutable order records + append-only fill log — cleanest audit trail, slightly more storage
  • Mutable order record with fill history — simpler queries, update concurrency issues
  • CQRS — separate write model and read model — high flexibility, high complexity

• Settlement: synchronous vs asynchronous ledger update?

  Impact: Synchronous ledger update per fill. Eventual consistency on financial state is not acceptable — a trader who fills a sell order must not be able to place a buy that exceeds their resulting balance.

  • Synchronous ledger update per fill — financial state always consistent, simpler reconciliation
  • Asynchronous ledger via queue — higher throughput, eventual consistency, reconciliation complexity
  • Batch settlement (end of day) — legacy pattern, unacceptable for crypto-native exchanges

What PROPELOO builds.

• CEX Matching Engine

  Full matching engine for a centralized crypto exchange — order book, risk pre-checks, execution journal, ledger updates, WebSocket market data, FIX gateway.

• Spot Trading Engine

  Spot-only matching engine for simple buy/sell markets — price-time priority, limit and market orders, trade tape, REST + WebSocket API.

• Derivatives Matching Engine

  Futures and perpetuals matching with mark price, funding rate calculation, liquidation engine integration, cross-margin and isolated margin support.

• RFQ / OTC Matching

  Request-for-quote matching engine for OTC and institutional block trades — quote broadcast, counterparty selection, deal confirmation, settlement.

• Internal Transfer Pricing Engine

  Matching engine for internal currency conversion (e.g., stablecoin <-> USDC) within a FinTech or neobank — sub-second execution, treasury rebalancing.

• Matching Engine Audit & Replacement

  Review and correctness audit of existing matching engine, or incremental replacement using strangler fig pattern while maintaining live trading.

The matching engine stack.

Every component choice is driven by latency, durability and correctness requirements.

• Matching Core

  Stack: Go / Rust (low-latency core), LMAX Disruptor pattern, Lock-free queues, In-memory order book (custom BST), Append-only execution journal

• Market Data

  Stack: WebSocket (ws / gorilla/websocket), Redis Pub/Sub fan-out, Kafka (high-volume installs), Sequence numbers + gap detection, L2/L3 depth snapshots

• API & Gateway

  Stack: REST (order entry, cancellation), FIX 4.2/4.4 gateway, WebSocket order updates, gRPC (internal services), Rate limiting + auth

• Storage & Durability

  Stack: PostgreSQL (trade history, ledger), Redis (in-memory state hot cache), S3 (journal + snapshot archival), TimescaleDB (OHLCV), WAL-based replication

• Observability

  Stack: Prometheus + Grafana (latency p99, throughput), Order processing heatmaps, Fill rate monitoring, Alert on order rejection spikes, Distributed tracing (Jaeger)

Matching engine security: financial correctness is the threat model.

The attack surface of a matching engine is different from a web application — the threats are financial, not just data breaches.

• Order manipulation & spoofing

  Large orders placed and immediately cancelled to create false price signals. Defences: spoofing detection pattern (high cancel-to-fill ratio per client), per-client cancel rate limits, minimum order resting time for large orders, and alert-on-anomaly for suspected spoofing patterns.

• Self-trade prevention

  A participant filling their own orders inflates volume, creates false price discovery and in regulated markets is market manipulation. Self-trade prevention must be enforced in the matching loop — when an incoming order would cross with a resting order from the same account, the incoming order is cancelled (or the resting order, depending on configured STP mode).

• Race conditions and double-spend

  Two concurrent API requests submitting the same order, or submitting a buy when the previous fill has not yet updated the balance. Prevention: idempotency keys on order submission, synchronous balance check-and-reserve before order acceptance, atomic position update on fill.

• Kill switch and circuit breakers

  A malfunctioning algorithmic trader can flood the engine with thousands of orders per second. Per-account order rate limits, per-account position limits, a per-account kill switch and a market-wide halt are required safety mechanisms — they must work even when the engine is under maximum load.

• Audit trail integrity

  The execution journal must be append-only and tamper-evident. Regulatory disputes and client claims require proof of what happened. Journal entries must include microsecond timestamps, sequence numbers, and cryptographic hash chaining to detect any post-hoc modification.

• API authentication and order replay

  Order submission APIs must use HMAC-signed requests with timestamp and nonce to prevent replay attacks — an attacker who captures a valid order submission must not be able to replay it. Per-key HMAC with sub-5-second nonce window is the standard pattern.

From specification to live trading.

1. 01. Architecture Design

   Order model, matching algorithm, journal schema, API spec, market data schema. ADR documentation.

2. 02. Core Engine

   Matching loop, order book, price-time priority, order types, execution journal. Correctness test suite.

3. 03. Risk & Controls

   Pre-trade risk checks, position limits, kill switch, self-trade prevention.

4. 04. Market Data Pipeline

   WebSocket broadcast, depth updates, trade tape, sequence numbers.

5. 05. API & Gateway

   REST order API, WebSocket order updates, FIX gateway if required.

6. 06. Load Testing

   Sustained throughput testing, latency p99 under load, concurrent WebSocket client testing.

7. 07. Production Deployment

   Zero-downtime deployment, monitoring dashboards, runbooks, incident response plan.

Matching engines we have shipped to production.

Three high-performance order matching systems handling real exchange volume.

• Go-based spot matching engine processing 18,000 orders/second with sub-millisecond latency

  Challenge: Crypto exchange with growing volume needed a matching engine replacing their third-party vendor — in-house control, sub-millisecond matching, 50+ trading pairs, and zero matching errors on a system handling real user funds.

  Architecture: Per-pair matching goroutines with in-memory order book (red-black tree), FIFO price-time priority, atomic trade execution writing to PostgreSQL and publishing to Kafka simultaneously, Redis for real-time price feed, gRPC API.

  Outcome: 18,000 orders/second peak throughput, 0.4ms median matching latency, 99.999% matching accuracy in 12-month operation, reduced infrastructure cost £40K/month vs vendor.

• Rust matching engine for perpetual futures with mark price and liquidation integration

  Challenge: Derivatives exchange needed a matching engine for perpetual futures — same price-time priority as spot but integrated with mark price calculations, cross-margin risk engine, and liquidation order prioritisation.

  Architecture: Rust async runtime (Tokio) for maximum throughput, per-market matching loop, liquidation orders bypass queue and match at best available price, mark price updates trigger margin checks, atomic settlement across matching and risk engine.

  Outcome: 45,000 orders/second capacity, 0.18ms median latency, zero instances of incorrect liquidations in 8 months of operation, handled 3x volume spike without degradation.

• Request-for-quote matching engine for institutional OTC crypto trading

  Challenge: Crypto prime broker needed an RFQ matching system — institutional clients broadcast quote requests, multiple market makers respond with firm prices, client selects the best quote and trade executes.

  Architecture: RFQ broadcast to eligible market makers via WebSocket, quote collection with 30-second expiry, best-price selection algorithm, trade execution with bilateral settlement instructions, market maker performance scoring.

  Outcome: 450 RFQs per day, average 4.2 market maker responses per RFQ, best-price improvement over TWAP 0.12%, 99.6% quote-to-fill rate.

Frequently Asked Questions