Most crypto exchanges die in the same place: not the UI, not marketing — the architecture underneath. A trading platform looks like a CRUD app from the outside, but it behaves like a real-time system with money at stake. After working through the components of a production-grade exchange, here is the architecture that actually holds up, and the failure modes of the shortcuts.
1. The matching engine is a state machine, not a service
The naive approach is a matching engine that reads and writes a database per order. It collapses around a few hundred orders per second.
A production engine keeps the entire order book in memory, organized as price-level queues with strict price-time priority. Every incoming order moves through one deterministic path:
validate → risk check → match against book → persist event → publish
Two details matter more than the algorithm:
- Single-writer principle. One thread (or actor) owns the book per trading pair. No locks, no races, deterministic replay.
- Event sourcing. Persist the intent and the outcome as an append-only event log. If the process crashes, you rebuild the book by replaying events — not by trusting the last database state.
Sub-5ms matching latency is achievable with boring technology when you stop hitting disk on the hot path.
2. Wallet infrastructure: separation of duties
The wallet layer is where exchanges lose funds. The architecture that survives:
- Hot wallet — small float, online, handles withdrawals up to a threshold.
- Warm/cold storage — the treasury. Multi-sig or MPC, withdrawal requires human approval.
- A reconciliation daemon — independently scans every chain and asserts that on-chain reality matches the ledger. It never trusts the deposit service's word.
Deposits and withdrawals are state machines with explicit confirmation counts per chain. "Crediting on 1 confirmation" for BTC is how you get double-spent.
3. The ledger is the product
Every balance change — trade, deposit, withdrawal, fee — is a double-entry ledger entry. Not a balance column you increment.
This gives you three things for free: complete audit trails, trivial reconciliation, and the ability to answer "why does user X have Y" years later. Exchanges that skip this spend their second year writing it anyway.
4. Liquidity from day one
An empty order book is a death spiral: no liquidity → no traders → no liquidity. Two proven patterns:
- Internal market-making — a quoting bot that maintains a tight two-sided book on your own venue, funded from your treasury.
- External liquidity bridging — mirror depth from a major exchange and hedge fills back-to-back. Your users see a deep book; your risk desk sees net-zero exposure.
5. KYC, admin, and the boring 40%
Roughly 40% of exchange code is not trading: KYC review queues, role-based admin access, fee configuration, withdrawal approvals, and audit logs. The architectural rule: admin actions are signed, permissioned operations in the same event log as trades — never direct database writes.
6. Buy vs. build
Building all of this from scratch is an 18-month, multi-million-dollar project — and then you maintain it forever. The pragmatic middle ground that has emerged is production-grade exchange software with full, unencrypted source code: you own the stack, can audit every wallet line, modify the fee engine, and deploy on your own infrastructure — without writing a matching engine from zero.
This deep-dive reflects the architecture used by Codono, self-hosted crypto exchange software with full source code — spot, futures, margin, and P2P modules, a 50+ chain wallet system, and native apps under a one-time license. Live demo and docs at codono.com.
What architectural piece bit you hardest when building trading infrastructure? Matching engine determinism, wallet reconciliation, or liquidity?
Top comments (0)