Payments, an interactive architecture walkthrough
Stock trading platform: how the architecture works
How a trading platform sequences every order into a deterministic in-memory matching engine, replicates it by replay, and settles trades separately.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate.
Interactive diagram
Overview
A stock trading platform accepts buy and sell orders, matches them into trades, publishes prices and settles the results. At its centre is a matching engine that keeps an in-memory order book per symbol and matches orders in price-time priority. Orders reach it through gateways that speak FIX for brokers and HTTPS for apps, after a risk check has reserved the account's cash or shares.
Every accepted command is given a single sequence number and written to a journal before matching. Because the engine is deterministic, replaying the journal reproduces the same books and trades, so a standby engine fed the same sequence can take over without differences, and recovery loads a snapshot and replays the rest. Market data, settlement and surveillance consume the engine's output asynchronously. This is a simplified learning design, not any exchange's actual architecture.
Trade-offs and what changes at scale
A single-threaded engine per symbol shard avoids locks and keeps latency low and predictable, but one very active symbol is bounded by one core, so symbols are spread across shards. Sequencing and journaling every input before matching adds a little latency in exchange for exact recovery. Pre-trade reservations prevent overspending but tie up funds for resting orders. At larger scale the work is mostly about tail latency and fairness: kernel-bypass networking, colocated gateways and keeping market data equal for every participant.
How it works, step by step
The walkthrough above, as text. Each step lights up the components named under it.
Brokers connect to the Order Gateway over FIX sessions and retail apps over HTTPS, and the gateway authenticates them and throttles each session. FIX carries messages such as new order and cancel request in a standard format the industry already uses.
Pre-trade Risk checks that the account can afford the order and that its price is within a band around the last trade, then reserves the cash or shares. Reserving before matching means a trade can never exceed what the account holds.
The Sequencer gives every accepted order and cancel a single sequence number and appends it to the Input Journal before matching. One total order of inputs is what makes the result reproducible.
The Matching Engine processes commands for a symbol one at a time on a single thread, with no locks. A deterministic single writer per order book is faster and simpler than coordinating many threads over shared state.
An incoming buy is matched against the lowest asks in the Order Books in price-time priority: best price first, then earliest order at that price. Whatever does not fill rests in the book, unless it was immediate-or-cancel.
The Standby Engine receives the same sequenced commands and builds the same books. If the primary fails, the standby takes over from the last sequence number with no lost or different trades.
The engine periodically writes its full state to the Snapshot Store. Recovery loads the latest snapshot and replays only the journal after it, instead of the whole day.
Each fill produces an execution report that the Matching Engine sends back through the Order Gateway to the order's owner. Reports carry the sequence number, so a client that reconnects can ask for anything it missed.
Book changes and trades go to the Market Data Publisher, and the Market Data Gateway streams quotes to apps. Market data is published after matching, from the same sequence, so every viewer sees events in the same order.
Executed trades are written to Trade Events, which Clearing & Settlement consumes outside the matching path. Settlement can take seconds or days without slowing matching, which takes microseconds.
Clearing & Settlement posts each trade to the Settlement Ledger and turns reservations in the Accounts DB into final cash and holdings. Trades carry their sequence number, so reprocessing after a crash does not apply a trade twice.
Market Surveillance scans trades and order activity for manipulation patterns such as spoofing or wash trading. Every tick is also kept in the Tick Store for audits and charts.
Sequence diagram
The same walkthrough as a UML sequence diagram, one lane per layer or group (18 components in all), left to right in the order a request reaches them, numbered by step. A loop on a lane is a step that stays inside that group. Solid arrows are synchronous calls, dashed are asynchronous.
Key components
Order Entrydomain
- Accounts DB: cash, holdings, reservations (postgresql)
- Order Gateway: FIX and REST sessions, throttles
- Pre-trade Risk: balance, position and price checks
Participantslayer
- Broker FIX Client: institutional order flow
- Trader App: retail orders over HTTPS
Matching Coreboundary
deterministic, in-memory, replicated
- Input Journal: every sequenced command, replayable
- Matching Engine: price-time priority, per-symbol shards
- Order Books: bids and asks per symbol, in memory
- Sequencer: one total order for all inputs
- Snapshot Store: periodic engine state (s3)
- Standby Engine: replays the same journal
Market Datadomain
- Market Data Gateway: streams quotes to apps (websocket)
- Market Data Publisher: book updates and trades
- Tick Store: every quote and trade (clickhouse)
Post-tradedomain
- Clearing & Settlement: updates cash and holdings
- Market Surveillance: spoofing, wash trades, limits
- Settlement Ledger: trades and balances (postgresql)
- Trade Events: executions in sequence order (kafka)
Observability
- Observability: latency percentiles, queue depth, rejects
Sources
Public writing this explainer draws on. Read these for what the real systems actually do.
Make it yours
Copy this diagram and its walkthrough into your own workspace, then change anything: swap Postgres for DynamoDB, add a cache, rewrite the narration. Free, and it uses no AI credits.
Related walkthroughs
- Stripe-style payments platformHow a payments platform tokenises cards, authorises a payment through the card networks, records it in a ledger, and settles funds to merchants.
- Digital walletHow a digital wallet records every movement in a double-entry ledger, makes retries safe with idempotency keys, and reserves funds for withdrawals.
- Distributed cacheHow a distributed cache places keys with consistent hashing, replicates shards, evicts entries, invalidates on writes and resists stampedes.
This is a learning explainer based on public engineering writing and general design practice. It is simplified, it is not the actual architecture of any company, and it may be inaccurate. Real systems differ in the details. Browse the library.