Crypto exchange architecture around the engine
With the engine settled, the rest of the crypto exchange architecture is a set of systems feeding it and reading from it. Each has a failure mode worth knowing before you design it.
Market data, and the feed nobody budgets for
Users want prices, depth and trade history, updating continuously, on every open client at once. That is a broadcast problem, and it is usually the first thing to fall over under load.
The volumes are not obvious from the trade count. One order that moves the top of the book generates an update for every connected client. Ten thousand connected clients and a busy book produce a message rate far higher than your trade rate, and the engine must not be the thing sending them.
So separate publication from matching. The engine emits a sequenced stream of events. A separate tier fans that stream out to clients, and that tier can be scaled, throttled and allowed to fail without touching execution.
Then decide what each client actually needs. A chart does not need every book update. A trading interface does. Tiering the feed, with snapshots plus deltas rather than full state, is the difference between a system that scales and one that does not.
Charting history is its own store. It is written once and read constantly at different resolutions, which is a different problem from the live feed and usually wants a different database.
The ledger, and why double-entry accounting returns
The ledger is where the money is, and it is the component most often built as an afterthought.
A balance column on a user row is not a ledger. It tells you what somebody believes is true right now and nothing about how it got that way. When a number is wrong, and one will be, you have no way to find out why.
Use double-entry. Every movement is recorded as matched entries that must balance, balances are derived from the entries rather than stored alongside them, and nothing is ever updated in place. The technique is centuries old and it is still the answer, because it makes an unexplained balance structurally impossible.
This buys you several things at once. Reconciliation against the chain becomes a comparison rather than an investigation. Regulatory reporting becomes a query. Disputes become answerable, because you can reconstruct any account at any past moment. And bugs become visible, because an imbalance is a loud failure rather than a quiet drift.
Design the reconciliation job on day one, not after the first discrepancy. It compares what the ledger says you hold against what the chain says you hold, it runs continuously, and it alerts on any gap. Where that job runs and how it is monitored is part of your cloud infrastructure design rather than an afterthought in application code.
Blockchain integration and on-chain settlement
Blockchain integration on a centralized venue is narrower than people expect. Trades do not touch the chain; only deposits and withdrawals do.
That makes it a boundary problem, and boundaries are where the awkward cases live.
Confirmations: how many before you credit a deposit? Too few risks a reorganisation reversing it. Too many makes users wait. The answer differs per network and it is a policy decision, not a default.
Fees: network fees move, sometimes sharply. Absorb them and your margin moves with the network. Pass them on and you need current estimates at the moment of withdrawal. Either way the fee logic is real code with real edge cases.
Failures and stuck transactions: a withdrawal broadcast but not confirmed, a fee too low to be picked up, a node out of sync. Each needs a defined response, because each will happen.
Multiple networks: every additional chain is a new integration, new confirmation rules, new fee behaviour and new failure modes. Listing an asset on three networks is three integrations, not one. The same discipline applies to any building on blockchain project, and it is the reason asset listing is slower than roadmaps assume.
Run your own nodes or use a provider. Providers are faster to start and become a dependency with an outage profile you do not control. Own nodes cost operational effort and give you certainty. Most teams start with a provider and regret not planning the migration.
Crypto exchange security beyond the wallet
Crypto exchange security discussion usually stops at the wallet. The wallet is where the assets are; it is rarely where the attack starts.
Account takeover is the common route. Credentials leak, an attacker signs in, changes the withdrawal address and withdraws. The keys were never touched. The controls that matter are ordinary: strong authentication, a cooling period after a withdrawal address changes, notification on every sensitive action, and anomaly detection on withdrawal patterns.
The admin surface deserves more attention than it usually gets. Internal tooling can move funds, adjust balances, freeze accounts and change limits. It needs the same controls as the customer-facing system and usually has fewer, because it was built for colleagues. Treat every administrative action as requiring authorisation, logging and, for anything that moves value, a second approver.
The withdrawal path is worth designing as a pipeline rather than an endpoint. Request, risk score, authorise, queue, sign, broadcast, confirm. Each stage is a place to stop something wrong, and a single synchronous endpoint gives you none of them.
And test it properly. Independent security testing on this class of system is not optional, and the useful test is not only the network perimeter. It is the withdrawal flow, the admin surface and the account recovery path, because that is where the money leaves.
