System Architecture

System Architecture

The stock exchange is structured as a collection of independent processing units, each responsible for a defined set of listed symbols. This separation allows the system to scale horizontally while preserving strict price–time priority for every individual order book. Symbols are never split across processing units; at any moment, a symbol is owned by exactly one execution path, ensuring deterministic behavior and eliminating cross-node coordination during matching.

Orders enter the exchange through gateway processes, which terminate client connections and perform protocol decoding, validation, and basic pre-trade checks. Once an order is accepted, it is routed to the processing unit responsible for the corresponding symbol. From this point forward, all handling of the order occurs within that unit, preserving locality and reducing latency.

Within each processing unit, a sequencer establishes the definitive order in which all incoming messages are processed. Every accepted order is assigned a monotonically increasing sequence number and written to an append-only write-ahead log before any state mutation occurs. This log defines the authoritative history of the exchange for that unit and serves as the basis for recovery, replication, and auditing. The sequencer then delivers the ordered messages to the matching engine through an in-memory channel optimized for low latency.

The matching engine maintains the in-memory limit order books for all symbols owned by the unit. It processes incoming messages strictly in sequence order and applies the exchange’s price–time matching rules without parallelism. The matching engine is intentionally single-threaded per unit to avoid locks, races, or non-deterministic execution paths. All updates to order state and all trade executions originate exclusively from this component.

To ensure high availability, each processing unit operates in a leader–standby configuration. The leader actively processes orders and produces execution and market data events. The standby node continuously streams and replays the leader’s write-ahead log, maintaining a nearly identical in-memory state. If the leader fails, the standby can assume leadership after completing any remaining replay, allowing order processing to resume without rebuilding the order books from scratch.

Market data generated by the matching engine is published through a dedicated distribution path. Updates are sent using UDP multicast to ensure that all subscribers receive messages at the same wire time. To address packet loss inherent in multicast transport, each message carries a sequence number, allowing clients to detect gaps and request retransmission from specialized recovery services. These retransmission services cache recent data in memory and fall back to persistent logs when necessary.

This architecture cleanly separates concerns between order intake, sequencing, matching, persistence, and data dissemination. By enforcing a single source of ordering and limiting mutable state to well-defined execution paths, the system achieves predictable latency, deterministic outcomes, and fast recovery while remaining scalable across symbols and message volumes.