How to Choose a Matching Engine

When building a trading product, the "Technology Choice" isn't just about implementation details. It directly determines two things: User Trust and Market Viability.

This guide compares architectures by asking the hard questions:

• Where do they fail?

• Why do they lose orders?

• Why are they slow?

The 3 Nightmares of Exchange Products

From a user/product perspective, technical failures manifest as:

1. The "Ghost" Order (Reliability): User clicks "Buy", the spinner spins, and... nothing happens. Or worse, it says "Failed" but money is gone.

2. The "Laggy" Fill (Latency): User sees a price of $100, clicks "Buy", but gets filled at $105 because the engine took 2 seconds to process it.

3. The "Unfair" Wick (MEV/Slippage): The price hits the user's stop-loss, liquidates them, and instantly bounces back.

---

Architecture Comparison

1. The "Web2 Database" App (Postgres / MySQL)

Most common MVP approach.

• How it works: Uses START TRANSACTION, SELECT FOR UPDATE to lock user balances and order rows in a SQL database.

• The Failure Mode: Deadlocks & The "Ghost" Order.

  • Why: SQL databases are optimized for storage safety, not sequential throughput. When 1,000 users try to buy "ETH" at the same time, they all fight for the same row lock on the Orderbook table.

  • Result: The database hangs. Requests time out. The web server crashes. Users don't know if their order went through.

• TPS Cap: ~500 - 1,000 TPS before user experience degrades drastically.

2. The "On-Chain AMM" (Uniswap Forks)

The default DeFi approach.

• How it works: Logic lives entirely in a Smart Contract. Order matching is algorithmic

  YES + NO = 1

• The Failure Mode: The "Laggy" Fill & The "Unfair" Wick.

  • Why: Every "order" is a blockchain transaction. It waits in the mempool (seconds to minutes).

  • Result:

    • MEV: Bots see the transaction in the mempool and "sandwich" it, giving the user a worse price.

    • Slippage: In volatile markets, the price moves while the transaction is pending.

• TPS Cap: 10 - 50 TPS (Blocked by Chain throughput).

3. The "Hybrid Sequencer" OrderbookTrade(https://www.orderbook.trade/)

The Modern Exchange Standard (Binance, Solana, dYdX).

• How it works:

  1. Off-Chain Matching: 100% In-Memory, Single-Threaded Sequencer (LMAX Architecture).

     No DB locks.

  2. On-Chain Settlement: Batched proofs for security.

• The Solution:

  • Reliability: The Sequencer processes events one-by-one. No race conditions. If it enters the pipe, it will be processed.

  • Latency: < 5ms matching. No database I/O on the critical path.

  • Fairness: FIFO (First-In-First-Out). No "Gas Wars" or reordering.

• TPS Cap: 100,000+ TPS.

---

The Decision Matrix

Metric	Database App (Web2)	On-Chain AMM (DeFi)	Hybrid Sequencer (Orderbook.trade)
Max TPS	~1k (DB Locks)	~50 (Block Time)	100k+ (CPU Bound)
Latency	200ms+	12s+ (Block Time)	< 5ms
Dropped Orders	High at peak load	High (Reverts)	Near Zero
MEV Protection	Internal (Trust Admin)	None (Public Mempool)	Sequenced (FIFO)
Custody	Custodial (Risk)	Self-Custody	Self-Custody
Ideal For	E-commerce, Slow mkts	Long-tail tokens	Active Trading, Perps, Betting

Verdict

• If you are building a Shop (buy once, hold), a Database is fine.

• If you are building a Swap for obscure tokens, an AMM is fine.

• If you are building a Pro Exchange or Prediction Market where price and speed matter

  • You need a Hybrid Sequencer.