How to Build an Exchange: The Entire Market in One Ordered Log
Building an exchange is never straightforward. Most of the work sits in the components around the core: connectivity, market data, drop copies, reporting. Yet the core, the trading engine itself, is the part people most often get wrong.
An exchange makes two demands that pull in opposite directions. The matching engine needs one stream that holds every order in a single order. Every trader needs a stream of their own: the orders they sent and the fills they got back. Traditional streaming platforms give you append-only logs, but no honest way to get both views of the same data.
AlgoX2 offers a reference architecture for a fault-tolerant exchange that does. This is the platform Polymarket, AlgoX2’s biggest client, is building its exchange on.
Matching is a function of the log
Start from what the matching engine is. It receives a fully ordered stream of incoming orders and matches them. Matching is a deterministic function of the contents of the stream so far. Given the same orders in the same order, it produces the same trades, every time.
The engine publishes those trades back into the same log. The result is a total transaction log: fully ordered, verifiable and immutable. Market data, drop copies and every other output are built from it.
Because it is a single log, you can run the accounting on it. You can check that this person spent this money, that person received it, and everything adds up.
Every trader has a stream too
The trouble is the second view. Each user of the exchange has their own sequence of orders and fills, and they want to read it as a stream of its own. A conventional platform makes you choose: one big partition the engine can read in order, or one stream per user that the engine cannot see as a whole.
Streams inside streams
AlgoX2 solves this with recursive indexing. A stream can contain other streams, interleaved into it. All of it is presented through a file namespace: you create entries in a directory, and declare that one is to be interleaved into another.
So the exchange creates one stream per user and arranges them to interleave into a single partition. The matching engine reads that partition, which holds the entire input of every user in one order.
The data is indexed twice: once along the partition, and once along each user. A trader publishes with idempotent, exactly-once semantics and sees only their private substream. The exchange’s internal processes see the whole partition. Interleaving and atomic recursive indexing are a native publishing mode of AlgoX2, which is what makes this part of the exchange relatively easy to build.
Everything downstream reads the log
The rest of the exchange follows the same pattern. Each downstream component reads a single log and produces some output from it. Market data is one such component. A drop copy is another. None of them needs to coordinate with the matching engine, because the log already says everything that happened, in order.
The full reference architecture is written up in Exchange Architecture on Streams. It applies to stock exchanges, internalization engines, dark pools and crypto exchanges alike.
One log for the market, one stream for each trader, and both are the same data. That is what lets an exchange be fast, fault-tolerant and auditable at once.
Watch the video
Want more context on the platform? Read about the product, or get in touch with us on the contact page.