Design Stock Exchange - A Deep Dive
#107: System Design Stock Exchange - Part 3
Share this post & I'll send you some rewards for the referrals.
Block diagrams created with Eraser.
Last month, I launched Design, Build, Scale… the newsletter series that will elevate your software engineering career.
This email (Part 3) is a little longer than the previous two, so I’ll get straight into it…
Key components of an exchange are:
Broker - allows people to buy and sell stocks on the exchange.
Gateway - entry point for brokers to send BUY or SELL orders to the exchange.
Matching Engine - matches BUY and SELL orders to create trades.
Order Processing Workflow:
User creates a BUY or SELL order through the broker.
Gateway validates the order: authentication, check request format & rate limiting.
Then it forwards the request to the order manager. It performs risk checks using rules defined in the Risk Manager.
Risk manager verifies whether the user’s wallet has sufficient funds. Plus, it freezes the required amount in the wallet to prevent double-spending.
Order Manager sends the request to the Matching Engine.
Matching Engine keeps an in-memory “order book” for each stock. It matches BUY and SELL orders based on price and time priority.
After a match occurs, the Matching Engine creates two executions (fills). One for the buyer. One for the seller.
Matching Engine distributes trade results as market data to clients through the Gateway. It uses UDP multicast1 for efficiency.
Most steps “before and after” matching run in parallel to BOOST throughput.
Onward.
Start building AI backends–Agents as microservices (Sponsor)
Chatbots and copilots are just the surface.
The real shift is happening underneath, where AI agents work behind the scenes, making smart decisions that developers used to hardcode.
AgentField is the open-source control plane for that:
Run agents as services
Discover services/agents
Coordinate tasks asynchronously
Use cryptographic IAM and audit trails
Use it to build AI-native backends that can reason about orders, customers, payments, and incidents (while following the rules YOU set).
You focus on the logic. AgentField handles running it in production.
Explore the code on GitHub: https://github.com/Agent-Field/agentfield
Try examples, test features, and ⭐ the repo if it helps!
New to AI backends? Start here: https://www.agentfield.ai/blog/posts/ai-backend
See why autonomous backends are crucial for system design.
Want to run 1000s of agents? Read this: https://agentfield.ai/docs
Learn how to run agents safely at scale.
FIX Protocol
Broker send orders to the gateway using the Financial Information eXchange (FIX) protocol (for institutional clients).
FIX is a text-based protocol. Although reliable, it’s slow because text parsing consumes CPU. Gateway uses a FIX engine to receive and send FIX messages.
You can build your own engine for ultra-low latency, or buy a pre-optimized commercial one.
Exchange streams market data using FIX Adapted for STreaming2 (FAST).
It’s much faster because it’s a binary, compressed version of FIX... binary encoding is compact and easy for CPUs to parse.
Many exchanges provide even faster binary protocols for high-frequency trading:
Integrated Trade Capture Handler (ITCH) - a fast market data feed
Order Unified Communication Handler (OUCH) - a fast order entry protocol
These avoid text parsing and are specifically designed for low-latency trading.
Let’s keep going!
Gateway
It accepts connections from brokers and supports REST + WebSocket APIs3 (for retail traders).
Gateway could use Nginx server for HTTPS termination and WebSocket routing. Plus, exchange could run many gateway servers in parallel behind a load balancer for high availability.
Gateway:
Tracks sequence numbers of each client,
Normalize and validate incoming messages,
Protects matching engine from malformed or abusive client traffic,
Uses TCP backpressure4 to slow down misbehaving or overloaded clients automatically,
Allows only ONE outstanding order per client to maintain strict, deterministic ordering.
Exchanges used to have MANY gateways (some faster, some slower).
But traders exploited this by:
Flooding slower gateways with junk orders to delay competitors,
Routing orders only through the fastest gateway (unfair advantage).
So modern exchanges use a SINGLE gateway for all clients of the “same class”.
This means all clients in the same class (institutional clients, retail traders) have identical latency5. Thus ensuring fairness and reducing system load.
Here’s how Gateway handles concurrency:
Inbound (broker → gateway):
Assigns one thread per TCP connection
Parses messages and publishes them to a Disruptor ring buffer
Disruptor efficiently distributes events to internal services (order manager, risk checks,...)
Outbound (matching engine → broker):
Outbound events come through the ring buffer
Ring buffer dispatches events to subscribed services
Each session has its own outbound handler thread
If a client is slow, backpressure (ring buffer fills up) prevents system slowdowns
NOTE: Inbound and outbound paths share no mutable state.
Wallet
A wallet stores a user’s funds & assets for trading.
But there’s a risk of DOUBLE SPENDING if two orders from the same user arrive at once… and both threads try to read the “same” balance.
Example:
Thread A reads balance X and subtracts Y
Thread B reads balance X and subtracts Z
Here are three ways to prevent this problem:
1 Mutex Locks
Only one thread updates the user’s balance at a time. This is safe, but it significantly slows down the system.
2 ConcurrentHashMaps
They allow fast (parallel) reads/writes if keys fall into different segments. Yet it doesn’t protect the correctness of multi-step operations (read → modify → write).
3 Database Row-Level Locking
Exchanges rely on SQL databases (like MySQL InnoDB) because they:
Support ACID (safe transactions)
Provide row-level locking, so two threads cannot update the same user’s balance at once
Plus, this approach makes the read → modify → write operations safer.
Sample Database Schema
user_account (user_id, balance)wallet (user_id, symbol, quantity)stock (symbol, price)
Tables can be sharded by “user_id” for performance.
Data Structures
account balance -
HashMap {user_id: balance}stock price -
HashMap {symbol: price}
Ready for the next technique?
Disruptor Pattern
Disruptor is a concurrency model that doesn’t use locks.
It’s built as a ring buffer (fixed-size circular array with up to 20 million slots).
Imagine the ring buffer as:
“super-fast, in-memory queue for passing events between threads.”
Producers write events; consumers read them in order.
Each thread maintains its own sequence number, so there is no locking, blocking, or contention.
A disruptor offers:
high throughput,
microsecond-level latency.
It’s excellent for workloads where many components must process the same event.
Here’s WHERE the stock exchange uses the disruptor:
1 Gateway
Gateway publishes incoming orders to an input disruptor.
It allows many tasks to run in parallel (without blocking each other), such as:
journaling to disk
unmarshalling (parsing messages)
assigning global sequence numbers
replicating events to standby engines
Each step is independent; disruptor provides high throughput without locks.
2 Order Manager
Order manager uses disruptors to broadcast events to various internal consumers, such as:
risk checks
routing logic
audit/journal writers
user balance service
sequence enforcement
Each consumer reads using its own sequence counter,,, so they never block each other.
3 Market Data
Output disruptors take results and prepare them for network output:
execution reports
market data updates
client notifications via gateway
Each topic (e.g., trades, market data) gets its own disruptor to avoid interference.
Ready for the best part?
Reminder: this is a teaser of the subscriber-only newsletter series, exclusive to my golden members.
When you upgrade, you’ll get:
High-level architecture of real-world systems.
Deep dive into how popular real-world systems actually work.
How real-world systems handle scale, reliability, and performance.