1,000,000 messages/sec hypothetical peak
A hypothetical burst of new, cancel and modify messages. The duration and per-symbol skew require separate assumptions.
FinancialPrincipal Level
Matching-Engine Design with a Price-Time Order Book
Trace FIFO priority, partial fills and cancellation in a hypothetical continuous limit book, then reason about sequencing, journal capacity and recovery.
How does a price-time matching engine work?
For this hypothetical continuous limit order book, one sequenced writer per symbol chooses the best eligible opposite-side price, then the earliest order at that price. It fills up to the smaller remaining quantity, repeats while prices cross, and rests any unfilled limit quantity. Separate order entry, durable sequencing, matching and market-data publication. Real venues have additional rules; this is an interview learning model, not a production exchange design.
Worked Example
Price-time order-book example
Use one fictional symbol, integer price ticks and fictional quantity units. Process commands in sequence order. All orders are displayed, good-until-cancelled limit orders. This simplified continuous book excludes hidden orders, auctions, routing, fees and self-match rules. Fills use the resting order’s price.
Sequence 1. Rest sell A
Add 5 units at 100 ticks.
Asks in priority order: A: 5 units at 100 ticks. No bids.
Sequence 2. Rest sell B
Add 4 units at 100 ticks.
Asks in priority order: A: 5 units at 100 ticks; B: 4 units at 100 ticks. No bids.
Sequence 3. Rest sell C
Add 6 units at 101 ticks.
Asks in priority order: A: 5 units at 100 ticks; B: 4 units at 100 ticks; C: 6 units at 101 ticks. No bids.
Sequence 4. Buy D crosses the book
Submit a limit buy for 7 units at up to 102 ticks. The lowest ask wins first; at the same price, first in is first out (FIFO).
Fill 5 units from A at 100 ticks then 2 units from B at 100 ticks. D is fully filled. Remaining asks: B: 2 units at 100 ticks; C: 6 units at 101 ticks. No bids. B keeps its place for its unfilled quantity.
Sequence 5. Cancel the remainder of B
Remove B’s remaining 2 units. The earlier fill is unchanged.
Remaining asks: C: 6 units at 101 ticks. No bids.
Sequence 6. Buy E does not cross
Submit a limit buy for 3 units at 100 ticks. The best ask is 101 ticks, above this buy’s limit.
No fill. E rests as a bid for 3 units at 100 ticks. Asks remain C: 6 units at 101 ticks.
Rehearse why A fills before B, why C does not fill, and why cancelling B cannot undo its execution. The log must preserve this sequence, integer quantities, order identifiers and the rule version so replay makes the same decisions. This is an educational algorithm trace, not production trading code or financial advice.
Target Scale
Engineering Scale & Performance SLAs
Illustrative interview sizing for the whole modeled service. These are assumptions and targets, not measured exchange or ClawPad results.
100,000 hypothetical participants
An assumed participant population; this is not a measured daily active user count.
64 GB/day raw; 192 GB/day with 3 copies
Raw journal payload only, using decimal GB. Copies are included only in the second value; retention and overhead are separate.
Match-core target p99 < 15 microseconds
An illustrative target from delivery of a sequenced command to the match core through its in-memory state update. Excludes network, risk checks, durable commit and response delivery. Measure end-to-end latency separately.
Stage 01
Functional & Non-Functional Requirements
Establish clear problem boundaries before proposing architectural components.
Core System Capabilities
- Accept new and cancel limit-order commands; define modification priority rules explicitly before extending this model. FIX or an OUCH-style binary interface belongs at order entry.
- Maintain a deterministic price-time limit book per symbol using integer price ticks and sequencer order at equal prices.
- Execute trades when buy prices cross sell prices; generate trade execution reports.
- Publish ordered execution and book-update events separately from private order responses; define snapshot and gap-recovery behavior for feed consumers.
Reliability & Latency SLAs
- Deterministic replay: the same committed sequence, starting state and rule version must reproduce orders, fills and cancellations without reading wall-clock time during matching.
- Treat p99 match-core latency under 15 microseconds as an illustrative target. Benchmark the actual workload and report end-to-end percentiles separately.
- Acknowledge acceptance only after a sequenced command reaches the chosen durable quorum commit point. Define recovery and rejection behavior when that quorum is unavailable.
Stage 02
Capacity Estimation Math
Keep daily message volume, burst rate and copy count separate. All rows use the same whole-service scope.
Assumptions and measurement limits
The fixed 64-byte message is an editorial payload assumption, not the size of every FIX, OUCH or ITCH message. Order lifecycle messages include new, cancel and modify commands; they are not all executions.
The 24-hour average is only an arithmetic comparison. A real workload needs market hours, burst duration, symbol distribution and market-data fanout. Daily totals do not establish peak capacity.
Nasdaq’s references illustrate price-time priority and distinguish OUCH order entry from ITCH market data. This model omits venue-specific priority exceptions and order types. The references do not substantiate this design’s capacity or latency targets.
| Dimension | Calculation Formula | Estimated Result |
|---|---|---|
| Hypothetical peak message rate | 1,000,000 new, cancel or modify messages/second at peak | A sizing assumption for the whole modeled service, not a sustained rate or a benchmark |
| Daily average over 24 hours | 1,000,000,000 messages/day ÷ 86,400 seconds/day | About 11,574 messages/second; intraday distribution is unspecified |
| Daily raw journal payload | 1,000,000,000 messages/day × 64 bytes/message | 64 GB/day (decimal GB) across the whole modeled service, before copies |
| Daily payload across copies | 64 GB/day × 3 total copies | 192 GB/day of payload only; excludes indexes, protocol framing, market-data output and headroom |
Sources for the example and design mechanisms
Reviewed October 23, 2026. Calculations use the hypothetical inputs above; source results are not benchmarks of this design.
Stage 03
Multi-Tier Architecture & Component Topology
How requests navigate ingress gateways, application logic, caching, and persistence.
FIX / OUCH-Style Order-Entry Adapter · Validation and Risk Checks · Request Identity Store
Authenticate participants, validate price ticks and quantities, enforce risk limits and deduplicate requests by participant and request identifier before sequencing. Parsing cost and network latency must be measured. OUCH handles orders and their updates; ITCH is a separate market-data protocol.
Single Logical Sequencer per Partition · Durable Quorum Journal · Committed Command Stream
Assign ordered sequence numbers and durably replicate each accepted command to a quorum before acknowledging acceptance. Matching consumes committed commands. An acceptance response is distinct from a fill report. Fence old leaders with an epoch, stop accepting when a quorum cannot commit, and preserve request identity and result mapping for safe retries.
Single-Threaded Match Core (C++ / Rust) · Price-Time Order Book (Doubly Linked Lists + B-Tree) · Memory Arena Allocator
Give each symbol one state owner, maintain FIFO queues at price levels, and apply committed commands in order. Preallocate where useful and profile allocations, queues and cache behavior. Deterministic results come from explicit rules and ordered inputs, not a guaranteed execution duration.
ITCH-Style Market-Data Encoder · Sequenced Feed Publisher · Snapshot and Retransmission Service
Publish sequenced book changes and trades after committed matching. Multicast can reduce repeated sends, but consumers can lose packets or observe different delays. Supply gap detection, recovery and snapshots; do not promise simultaneous arrival or equal market access.
Stage 04
Database Schemas & Partitioning Strategy
Entity models, indexing, and primary key partitioning.
PK: order_id
- order_id (UINT64 PK)
- symbol_id (UINT32)
- side (BUY/SELL)
- price_ticks (UINT64)
- quantity (UINT32)
- command_sequence (UINT64)
In-memory cache-line aligned C++ struct; price levels indexed via custom B-Tree with intrusive doubly linked list queues.
PK: match_id
- match_id (UINT64 PK)
- buy_order_id (UINT64)
- sell_order_id (UINT64)
- symbol_id (UINT32)
- execution_price (UINT64)
- matched_shares (UINT32)
- command_sequence (UINT64)
Store stable execution identifiers and command sequences for audit and idempotent downstream delivery. This sketch does not establish regulatory reporting compliance.
PK: account_id
- account_id (UINT32 PK)
- cash_balance_cents (UINT64)
- collateral_shares (UINT32)
- max_leverage_ratio (FLOAT)
A bounded in-memory risk view needs explicit freshness, reservation and recovery rules. Cache-friendly layout may help, but application code cannot guarantee L3 residency or a fixed access time.
Stage 05
Critical Architectural Trade-Offs
How to defend engineering compromises when challenged by interviewers.
Concurrency: Multi-Threaded Partitioned Engine vs Single-Threaded Core per Symbol
Option A: Multi-threaded order book with mutexes/spinlocks
Option B: Single-Threaded Engine per Symbol (LMAX Disruptor Pattern)
Rationale: A single state owner per symbol simplifies ordering and avoids concurrent mutation within that book. Partitioning symbols can add parallelism, but a hot symbol and shared risk limits can bottleneck it. CPU affinity and preallocation are options to measure; neither provides a fixed speedup or a latency guarantee.
Network Transport: TCP vs UDP Multicast for Market Data
Option A: TCP Point-to-Point connections
Option B: UDP Multicast (A/B Feed Architecture)
Rationale: Point-to-point TCP offers ordered delivery per connection and creates per-consumer backpressure. UDP multicast reduces sender fanout work on supported networks, while requiring application-level sequencing and loss recovery. Compare load, tail latency and recovery costs for the actual topology; neither transport guarantees equal arrival times.
Technical FAQ
Frequently Asked Questions: Matching-Engine Design with a Price-Time Order Book
Key interview questions and conceptual defenses.
How much journal storage does the example need?
The hypothetical 1,000,000,000 messages/day at 64 bytes/message produce 64 GB/day of raw payload, or 192 GB/day across 3 total copies. These are decimal GB for the whole modeled service, not each symbol partition. Indexes, protocol framing, market-data output, retention and operating headroom need separate budgets. The 1,000,000 messages/second peak is an assumption, not an all-day rate or a measured result.
Why choose an in-memory matching core instead of putting each match in PostgreSQL?
This model keeps ordered book mutation in one in-memory owner to make priority rules and replay explicit. PostgreSQL can still store accounts, configuration or query projections, and its suitability depends on the measured workload and durability requirements. A separate journal and core add recovery complexity; they do not establish that a relational database is universally too slow.
How does the modeled engine recover after primary failure?
Acceptance is acknowledged only after the sequenced command is durably committed to a quorum. Recover from a snapshot plus the committed log suffix using the same rule version, then verify the replay position before enabling writes. Fence the old leader with a new epoch so only one writer can commit. Preserve request and execution identifiers so retries cannot duplicate accepted commands or downstream effects. If a reply is lost after commit, the client may not know the outcome and must query or retry the same identifier. Promotion can take time; writes can be unavailable or rejected while quorum or leadership is unresolved. This is a design contract to test, not a promise of instant or lossless failover under every failure.
Does every exchange use this exact price-time model?
No. This example uses a simplified continuous book of displayed limit orders. Nasdaq’s overview describes price/time priority and also distinguishes displayed from non-displayed shares. Real rulebooks add order types, auctions, routing and other priority rules. State your interview assumptions before tracing the algorithm.
Simulate this architecture
Download ClawPad