A cryptocurrency exchange looks, from the outside, like a stock trading app — you place a buy or sell order, it gets matched, and your balance updates. But underneath, it is solving a much harder problem than a normal trading platform: it must be simultaneously a trading system (fast order matching) and a bank (custody of real digital assets, deposits and withdrawals to public blockchains, and money that can never simply be “wrong”).

Unlike a traditional stock exchange, where a central clearinghouse and regulated custodians handle settlement over days, a crypto exchange typically holds customer funds directly and must track exactly how much of each cryptocurrency every single user owns, at every single moment, with zero room for a rounding error or a lost cent — because unlike a typical web app, “wrong” here means real, often irreversible, financial loss.

1.1 A short history

Early cryptocurrency exchanges in the early 2010s were simple: a basic web server, a SQL database tracking balances, and a naive matching algorithm. As trading volume grew, exchanges rebuilt around dedicated matching engines borrowed from traditional finance, while adding an entirely new layer that stock exchanges never needed: managing actual on-chain wallets, watching blockchains for incoming deposits, and safely broadcasting outgoing withdrawal transactions. Several early exchanges suffered catastrophic losses from weak custody practices and sloppy balance tracking — these failures are why the modern architecture below treats the ledger and wallet layers as being just as critical as the matching engine itself.

This tutorial walks through both halves of that problem in depth: the fast, familiar trading half (a matching engine much like the one powering any traditional stock exchange), and the custody-and-correctness half that makes crypto exchanges uniquely demanding — a double-entry ledger that can prove, mathematically, that no money was ever created or destroyed, and a wallet architecture that keeps real on-chain assets safe from both external attackers and internal mistakes.

Let’s break down what “accurate, auditable balances while processing thousands of trades per second” actually demands.

Now let’s design the full system, box by box, including the load balancer and API gateway the platform needs at its edge, plus the ledger and wallet layers unique to a crypto exchange.

3.1 Component-by-component breakdown

The heart of this system’s correctness guarantee is double-entry bookkeeping — a centuries-old accounting technique, originally used by merchants long before computers existed, adapted here to guarantee that a software bug can never silently create or destroy money.

4.1 How double-entry bookkeeping works

Every balance-affecting event is recorded as a set of entries where the total of all debits exactly equals the total of all credits. If they ever don’t match, the system has a bug — and this can be checked programmatically after every single transaction, giving an automatic, continuous correctness proof.

4.2 Simplified Java example — recording a trade as a ledger transaction

public class LedgerTransaction {
    private final String transactionId;
    private final List<LedgerEntry> entries = new ArrayList<>();

    public void addEntry(String accountId, String asset, long amount, EntryType type) {
        entries.add(new LedgerEntry(accountId, asset, amount, type));
    }

    // Must be called before this transaction is allowed to commit
    public void validateBalanced() {
        Map<String, Long> netByAsset = new HashMap<>();
        for (LedgerEntry e : entries) {
            long signed = e.type() == EntryType.DEBIT ? e.amount() : -e.amount();
            netByAsset.merge(e.asset(), signed, Long::sum);
        }
        for (Map.Entry<String, Long> net : netByAsset.entrySet()) {
            if (net.getValue() != 0) {
                throw new IllegalStateException(
                    "Unbalanced ledger transaction for asset " + net.getKey());
            }
        }
    }
}

public class LedgerService {
    public void applyTrade(Trade trade) {
        LedgerTransaction txn = new LedgerTransaction(trade.id());

        txn.addEntry(trade.buyerId(), trade.quoteAsset(), trade.notional(), EntryType.DEBIT);
        txn.addEntry(trade.buyerId(), trade.baseAsset(), trade.quantity(), EntryType.CREDIT);

        txn.addEntry(trade.sellerId(), trade.baseAsset(), trade.quantity(), EntryType.DEBIT);
        txn.addEntry(trade.sellerId(), trade.quoteAsset(), trade.notional(), EntryType.CREDIT);

        txn.addEntry(EXCHANGE_FEE_ACCOUNT, trade.quoteAsset(), trade.feeAmount(), EntryType.CREDIT);

        txn.validateBalanced();  // fails loudly instead of silently corrupting balances
        ledgerRepository.commitAtomically(txn); // single atomic database transaction
    }
}

Notice the critical safety property: validateBalanced() runs before anything is written to the database, and the entire set of entries is committed as a single atomic database transaction. If any single entry fails to apply, none of them apply — there is no possible intermediate state where money exists on one side of a trade but not the other.

4.3 Fixed-point arithmetic for amounts

Just like a stock exchange’s prices, all cryptocurrency amounts must be represented as fixed-point integers (e.g., satoshis for Bitcoin, the smallest indivisible unit for each asset) rather than floating-point numbers. Floating-point rounding errors are exactly the kind of subtle bug that double-entry bookkeeping is designed to catch — but it’s far better to prevent the error entirely by never using floating-point representation for money in the first place.

4.4 Optimistic locking for balance reservation

Because thousands of users may be trading concurrently, the Balance Reservation Service uses optimistic concurrency control (a version number or compare-and-swap check on each account’s available balance) rather than heavyweight database locks, so that reserving funds for one user’s order never blocks another unrelated user’s order from being processed.

4.5 The matching engine itself

The matching engine used by a crypto exchange is architecturally almost identical to a traditional stock exchange’s matching engine: a single-threaded event loop per trading pair, maintaining an in-memory order book with price-time priority, and producing trade events for downstream settlement. This shared lineage is why so many crypto exchange matching engines were built by engineers who came directly from traditional finance trading system backgrounds.

public class CryptoOrderBook {
    private final TreeMap<Long, ArrayDeque<Order>> bids =
        new TreeMap<>(Comparator.reverseOrder());
    private final TreeMap<Long, ArrayDeque<Order>> asks = new TreeMap<>();

    // Runs on the single dedicated thread for this trading pair only
    public List<Trade> submit(Order incoming) {
        List<Trade> trades = new ArrayList<>();
        TreeMap<Long, ArrayDeque<Order>> opposite =
            incoming.isBuy() ? asks : bids;

        while (incoming.remainingQty() > 0 && !opposite.isEmpty()) {
            Map.Entry<Long, ArrayDeque<Order>> bestLevel = opposite.firstEntry();
            long bestPrice = bestLevel.getKey();
            boolean crosses = incoming.isBuy()
                ? incoming.limitPrice() >= bestPrice
                : incoming.limitPrice() <= bestPrice;
            if (!crosses) break;

            ArrayDeque<Order> queue = bestLevel.getValue();
            Order resting = queue.peekFirst();
            long fillQty = Math.min(incoming.remainingQty(), resting.remainingQty());

            long fee = computeFee(fillQty, bestPrice, incoming.feeTier());
            trades.add(new Trade(incoming.id(), resting.id(), bestPrice, fillQty, fee));

            incoming.reduceQty(fillQty);
            resting.reduceQty(fillQty);
            if (resting.remainingQty() == 0) queue.pollFirst();
            if (queue.isEmpty()) opposite.remove(bestPrice);
        }

        if (incoming.remainingQty() > 0) {
            TreeMap<Long, ArrayDeque<Order>> same =
                incoming.isBuy() ? bids : asks;
            same.computeIfAbsent(incoming.limitPrice(), k -> new ArrayDeque<>())
                .addLast(incoming);
        }
        return trades;
    }

    private long computeFee(long qty, long price, FeeTier tier) {
        // Maker/taker fee schedules are common: lower fees for resting
        // liquidity providers, slightly higher fees for aggressive takers.
        return (qty * price * tier.takerBps()) / 10_000L;
    }
}

Notice the fee calculation happens right at match time and flows directly into the trade record, which the Ledger Service then converts into the exchange fee credit entry shown in Fig 4.1. Just like the pure trading example, no locks appear anywhere in this loop — correctness comes entirely from having exactly one thread own this trading pair’s order book.

4.6 Maker-taker fee models

Most crypto exchanges use a maker-taker fee model to encourage liquidity: an order that rests in the book and provides liquidity (a “maker”) pays a lower fee than an order that immediately matches against existing liquidity (a “taker”). This fee logic lives entirely inside the matching engine’s trade generation step, keeping fee computation as fast and deterministic as the matching decision itself, rather than being calculated later during ledger settlement.

4.7 Order book data structure choices

The same price-level-map-plus-FIFO-queue structure used in traditional trading systems applies here: a sorted structure (balanced tree, skip list, or bucketed array for common tick sizes) keyed by price, with a time-ordered queue of orders at each level. Crypto markets add one wrinkle traditional equity markets rarely need to worry about at the matching engine level: extremely fine-grained decimal precision, since some assets trade in units far smaller than a traditional stock’s cent-based tick size. This is handled by choosing an appropriately scaled fixed-point integer representation per asset (for example, representing Bitcoin amounts in satoshis, the smallest indivisible unit) rather than trying to use one universal precision across every asset.

4.8 Self-trade prevention

Because many crypto traders run automated market-making bots that place both buy and sell orders on the same pair simultaneously, self-trade prevention becomes especially important: the matching engine checks whether a resting order and an incoming order belong to the same account before matching them, and if so, either cancels the smaller/newer order or skips to the next price level, depending on the configured self-trade prevention mode. Without this, a market maker’s own bot could unintentionally trade against itself, generating fees and confusing position tracking for no economic benefit.

Let’s trace one order from submission all the way through to a settled, ledger-recorded trade.

5.1 Order and balance states

5.2 Deposit lifecycle

Deposits follow a different, blockchain-driven lifecycle:

1. A user sends cryptocurrency to a unique deposit address generated for their account by the Wallet Service.
2. The Blockchain Node Gateway detects the incoming transaction as soon as it appears in the blockchain’s mempool (unconfirmed) and marks it PENDING — visible to the user, but not yet spendable.
3. Once the transaction accumulates the required number of confirmations (varies by asset — Bitcoin typically requires several confirmations, while some faster chains require fewer), the Ledger Service credits the user’s available balance via a balanced double-entry transaction.
4. The deposit is now CONFIRMED and fully usable for trading or withdrawal.

5.3 Withdrawal lifecycle

1. User submits a withdrawal request specifying asset, amount, and destination address.
2. The Withdrawal Risk Service evaluates the request (address allow-listing, daily limits, large-amount review) as detailed in the Security section.
3. If approved automatically, the Wallet Service processes the request — small withdrawals broadcast directly from the hot wallet; larger withdrawals queue for multi-signature approval from the cold wallet.
4. Once signed and broadcast, the Blockchain Node Gateway monitors the transaction until it reaches enough confirmations to be considered final.
5. The Ledger Service records the withdrawal as a debit against the user’s balance, balanced by a credit removing the corresponding amount from the exchange’s wallet-tracking account.

Every architectural decision here involves giving something up in exchange for something else. The table below makes these trade-offs explicit — the kind of reasoning worth walking through out loud in a system design interview, since interviewers usually care more about why a decision was made than the decision itself. As with the matching engine design borrowed from traditional finance, there is no single version of this system that is simultaneously the fastest, the cheapest, and the simplest to operate; the goal is choosing the right trade-off for each layer given what that layer actually needs to guarantee.

6.1 Key trade-offs

Let’s size the system for the stated scenario: thousands of trades per second, with an overall request scenario of millions of requests per minute.

7.1 Sizing the problem

• Assume 3,000,000 requests per minute at peak (orders, cancels, balance queries) = 50,000 requests/second average.
• Real trading volume is bursty — a sharp price move can cause a 5–10x spike in seconds, so design for 250,000–500,000 requests/second at brief peaks.
• Of these, only a fraction are actual trade executions — thousands of trades per second on the busiest pairs (like BTC/USDT), well within a single-symbol matching engine shard’s capacity.

7.2 Where the time goes

Note that ledger settlement is allowed a slightly larger budget than pure order matching, because it happens asynchronously after the trade is already matched — the user sees their order fill quickly, while the durable, auditable balance record catches up within single-digit milliseconds.

7.3 Scaling techniques

7.4 Capacity planning walkthrough

Let’s work through a concrete capacity plan for the stated scenario of millions of requests per minute and thousands of trades per second.

• Assumption: 3,000,000 requests per minute at peak, spread across roughly 200 actively traded pairs.
• Average per pair: 3,000,000 / 200 = 15,000 requests per minute per pair on average — roughly 250 per second. Comfortable for a single matching engine shard.
• Skew assumption: the top 10 pairs (BTC/USDT, ETH/USDT, and similar) might account for 60% of total volume — 1,800,000 requests/minute across 10 pairs = 180,000/minute per hot pair = 3,000/second. This is the “thousands of trades per second” scenario stated in the requirements, and it still fits comfortably within one dedicated core running an optimized single-threaded matching loop.
• Ledger write throughput: Each trade generates roughly 5 ledger entries (buyer debit/credit, seller debit/credit, fee credit). At 3,000 trades/second on the hottest pair alone, that’s 15,000 ledger entries/second just from that one pair — well within what a properly indexed, partitioned relational database cluster can sustain when writes are batched and committed as grouped transactions rather than one-by-one.

7.5 CAP theorem for the ledger

The ledger database, unlike the matching engine, genuinely faces a classic CAP theorem trade-off, because it must remain strongly consistent (an unbalanced or partially-applied transaction is never acceptable) even during network partitions between replicas. This is why the ledger favors Consistency over Availability during a partition: if the primary ledger node cannot confirm a transaction has been safely replicated, it is far better to briefly reject new trades from settling than to risk two replicas disagreeing about a user’s balance.

Contrast this with the order book cache, which favors Availability over Consistency — it’s acceptable for a balance shown in a UI to be a few hundred milliseconds stale, but never acceptable for the authoritative ledger balance used to approve a withdrawal to be stale or inconsistent.

A crypto exchange going down, or worse, applying incorrect balance updates during a failure, can mean real financial loss for users and the exchange alike.

8.1 Techniques for high availability

• Database replication with synchronous commit for the ledger database, ensuring a failover never loses a committed balance transaction.
• Hot standby matching engines per trading pair shard, replaying the write-ahead log to take over within milliseconds of a detected failure.
• Continuous reconciliation between the ledger’s total balances and the wallet service’s actual on-chain holdings, catching any drift automatically rather than waiting for a user complaint or manual audit.
• Automatic withdrawal circuit breakers that halt withdrawals immediately if reconciliation ever detects a mismatch beyond a tiny, expected tolerance (like unconfirmed network fees).
• Disaster recovery site with geographically separate infrastructure, including secure, separately-stored cold wallet backup material.

8.2 Why reconciliation is non-negotiable

The Mt. Gox collapse mentioned earlier happened, in large part, because there was no reliable automated process continuously checking whether the exchange’s internal ledger matched its actual on-chain holdings. A modern exchange treats this reconciliation loop as one of its most safety-critical pieces of infrastructure — often running every few minutes, with any detected discrepancy immediately halting withdrawals until a human confirms what happened.

8.3 RPO and RTO targets

8.4 Consensus for failover coordination

Just as in traditional trading system design, the failover controller that decides when to promote a standby matching engine or ledger database replica uses a consensus protocol like Raft, ensuring only one node can ever be treated as primary at a time — preventing a dangerous split-brain scenario where two nodes might independently accept and settle conflicting trades or ledger transactions for the same account.

8.5 Regular failover and reconciliation drills

Beyond testing matching engine failover, a crypto exchange must also regularly rehearse its reconciliation and withdrawal circuit-breaker path — deliberately injecting a controlled, simulated balance mismatch in a staging environment to confirm the alert fires, withdrawals actually halt, and the on-call engineer’s runbook actually works, rather than discovering gaps in that process during a real incident.

8.6 Disaster recovery for custody infrastructure

Disaster recovery for a crypto exchange extends beyond the usual “spin up infrastructure in another region” playbook, because cold wallet key material cannot simply live in a single data center without becoming a single point of catastrophic failure. Production exchanges typically split cold wallet signing key material across multiple geographically separated, physically secured locations using key-splitting schemes (such as Shamir’s Secret Sharing or hardware security modules with distributed multi-party approval), so that no single site’s loss or compromise can either lock the exchange out of its own cold storage or, worse, allow a single compromised location to unilaterally move funds.

Security here spans both typical web application concerns and crypto-specific custody risks.

9.1 Authentication and authorization

• Mandatory two-factor authentication, with additional step-up verification (like email/SMS confirmation) required specifically for withdrawal requests.
• API key scoping — a trading-only API key should never be able to authorize a withdrawal, even if leaked.
• Withdrawal address allow-listing, with a mandatory delay before a newly added withdrawal address can actually be used.

9.2 Wallet custody security

• Hot/cold wallet split — only a small percentage of total exchange funds sit in internet-connected hot wallets at any time, strictly limiting the maximum possible loss from a hot wallet compromise.
• Multi-signature approval for cold wallet withdrawals, requiring multiple independent human signers (often in different physical locations) before a large withdrawal can be broadcast.
• Automated sweeping of excess hot wallet balance into cold storage on a regular schedule, so the hot wallet never accumulates more than its intended operating buffer.

9.3 Deposit confirmation requirements

A deposit is only credited to a user’s ledger balance after a blockchain-specific number of confirmations (blocks mined on top of the deposit transaction), to protect against blockchain reorganizations that could otherwise let an attacker deposit funds, get credited, and then have the deposit transaction disappear from the canonical chain.

9.4 Withdrawal risk controls

• Velocity limits — maximum withdrawal amount per day/week per account, with larger withdrawals requiring manual review.
• Anomaly detection — flagging withdrawal patterns that deviate significantly from a user’s normal behavior.
• AML/sanctions screening on withdrawal destination addresses where technically feasible.

9.5 Cost optimization

Even in a system this focused on correctness and security, cost still matters at scale:

• Running the matching engine and ledger tiers on dedicated, right-sized infrastructure (since these benefit most from predictable performance), while running elastic, bursty tiers like the API Gateway and KYC screening service on auto-scaling cloud infrastructure that scales down during quiet trading hours.
• Tiered storage for historical trade and transaction data — recent data in fast, queryable storage, older records moved to cheaper cold storage after a retention window, while still meeting regulatory record-keeping requirements (often 5–7 years depending on jurisdiction).
• Batching blockchain withdrawal transactions where the underlying network supports it, reducing the per-transaction network fee cost passed on to users or absorbed by the exchange.
• Running blockchain full nodes for high-volume assets on dedicated infrastructure, while using third-party node providers for lower-volume, less frequently traded assets to avoid the operational cost of running infrastructure for every single supported blockchain.

9.6 Simplified Java example — withdrawal risk check

public class WithdrawalRiskService {
    public WithdrawalDecision evaluate(WithdrawalRequest request, AccountProfile profile) {
        if (!profile.isAddressAllowListed(request.destinationAddress())) {
            return WithdrawalDecision.reject("Address not on allow list");
        }
        if (profile.addressAddedAt(request.destinationAddress())
                .isAfter(Instant.now().minus(Duration.ofHours(24)))) {
            return WithdrawalDecision.reject("New address cooling period not elapsed");
        }
        long dailyTotal = ledgerService.sumWithdrawalsLast24h(request.accountId(), request.asset());
        if (dailyTotal + request.amount() > profile.dailyWithdrawalLimit(request.asset())) {
            return WithdrawalDecision.requireManualReview("Exceeds daily withdrawal limit");
        }
        if (request.amount() > profile.largeWithdrawalThreshold(request.asset())) {
            return WithdrawalDecision.requireManualReview("Large withdrawal requires review");
        }
        return WithdrawalDecision.approve();
    }
}

Notice how the check escalates in severity: hard rejection for policy violations (unrecognized address), automatic manual review for unusually large amounts, and straightforward approval otherwise — this tiered approach lets the vast majority of legitimate, routine withdrawals process quickly while still catching the higher-risk cases that genuinely warrant a human look.

Given the financial stakes, monitoring for a crypto exchange goes beyond typical latency and error-rate metrics.

10.1 Key metrics to track

10.2 Service Level Objectives (SLOs)

10.3 Approach

• Every ledger transaction’s balanced-books check result is emitted as a metric, not just logged, so a dashboard can show a real-time count of invariant violations (which should always read zero).
• Distributed tracing with correlation IDs across the order-to-settlement path, so a slow or failed trade can be diagnosed stage by stage.
• Async, non-blocking metrics emission from the matching engine’s hot path, exactly as in traditional trading systems, so monitoring itself never adds latency.
• Automated alerting wired directly to the withdrawal circuit breaker, so a detected reconciliation mismatch stops withdrawals before a human even has time to react.

10.4 Distributed tracing example

For the order-to-settlement path, a trace reconstructed from correlation-ID-tagged logs might look like this:

trace_id=a91f3c order_id=CL-2026-51029
  [gateway]      auth+validate        : 95us
  [oms]          enrich+kyc-check     : 48us
  [balance-svc]  reserve-funds        : 88us
  [matching]     match-and-fill       : 41us
  [queue]        publish-trade-event  : 22us
  [ledger]       apply-double-entry   : 3.1ms
  [ledger]       balance-check-passed : 0.2ms
  ------------------------------------------
  total order-to-settlement latency    : 3.6ms

Having this per-stage breakdown readily available (sampled for a subset of orders to control overhead) is invaluable when diagnosing exactly where latency creeps in — in this example, the ledger’s double-entry write dominates the total, which is expected and acceptable since it happens asynchronously after the user already sees their order filled.

11.1 Deployment practices

• Blue-green deployment for the API Gateway, OMS, and other stateless services, enabling zero-downtime releases with instant rollback.
• Extremely cautious, shadow-tested deployment for the Ledger Service and Matching Engine — changes here are tested against mirrored production traffic in a shadow environment, comparing every resulting balance change byte-for-byte against the current production system before going live.
• Separate, heavily restricted deployment pipeline for Wallet Service code, often requiring multiple independent approvals given its direct access to fund movement logic.
• Infrastructure as Code for reproducible, auditable environments across development, staging, and disaster recovery sites.

11.2 Cloud vs dedicated infrastructure

Many exchanges run their matching engine and ledger tiers on dedicated, right-sized infrastructure for predictable low-latency performance, while running elastic, bursty tiers (API Gateway, OMS, KYC screening) on auto-scaling cloud infrastructure. Blockchain node infrastructure is often run on dedicated, geographically distributed servers for reliability, since losing connectivity to a blockchain node means missing deposit detection entirely during that outage window.

11.3 Shadow testing for ledger and wallet changes

Before any change to the Ledger Service or Wallet Service reaches production, it runs in a shadow environment that receives a mirrored copy of real production events (trades, deposits, withdrawal requests) without ever actually moving real funds. The resulting balance changes are compared, entry for entry, against what the current production system produces for the same input. Any divergence — even a single satoshi — is investigated and resolved before the change is allowed anywhere near real customer funds.

12.1 Database choices

12.2 Why the ledger needs strong ACID guarantees

Unlike some other parts of a large system that can tolerate eventual consistency, the ledger database cannot: a double-entry transaction must be atomic (all entries commit or none do), consistent (the balanced-books invariant always holds), isolated (concurrent transactions don’t see each other’s partial updates), and durable (once committed, never lost). This is exactly what traditional relational databases with proper transaction isolation levels are built for, which is why the ledger typically stays on a strongly consistent relational database even as other parts of the system embrace eventual consistency for performance.

12.3 Partitioning strategy for the ledger database

Partitioning the ledger by account ID (using a hash-based scheme) works well because almost every ledger transaction only involves a small, fixed set of accounts — typically two trading accounts plus the exchange’s own fee account. As long as a single database transaction can span the specific partitions holding those particular accounts (achievable through careful shard co-location of frequently-paired accounts, or a two-phase commit protocol for cross-partition transactions), the system scales horizontally without sacrificing the atomicity that double-entry bookkeeping depends on.

The exchange fee account deserves special mention here: because nearly every trade touches it, it can become a hot partition under high load. A common mitigation is to maintain several fee sub-accounts (round-robining trades across them) and periodically consolidate them into a single reporting balance — trading a small amount of bookkeeping complexity for significantly reduced write contention on this one especially busy account.

12.4 Caching strategy

A read-only cache, updated asynchronously from the ledger’s committed transaction stream, serves fast “what’s my current balance” queries without hitting the ledger database directly for every single read — since balance-check reads vastly outnumber actual balance-changing writes.

12.5 Load balancing approach

Beyond the entry-point load balancer, internal routing sends orders to the correct matching engine shard using consistent hashing on the trading pair, exactly as covered for the order-matching path, ensuring every order for a given pair reaches the same shard in submission order.

The platform exposes multiple interfaces to different types of clients and integrations:

• REST/WebSocket API — used by retail trading apps and most third-party integrations for order submission, balance queries, and real-time trade/order updates.
• FIX Protocol — offered by many larger exchanges for institutional clients and market makers who need the same low-latency, industry-standard connectivity used in traditional finance.
• Webhook notifications — for deposit confirmations and withdrawal status updates, so integrating platforms don’t need to poll.

13.1 Microservices boundaries

• OMS never writes directly to the ledger — it only ever talks to the Balance Reservation Service and Matching Engine through their narrow, well-defined interfaces.
• Wallet Service is the only component with any blockchain private key access — no other service, including the Ledger Service, ever touches wallet signing material directly.
• KYC/AML Service is stateless per-request but backed by a fast, replicated identity and risk-status cache, so it doesn’t become a bottleneck in the order acceptance path.

13.2 Example — balance query API response

GET /api/v1/balances/BTC

{
  "asset": "BTC",
  "available": "1.50000000",
  "reserved": "0.25000000",
  "total": "1.75000000",
  "as_of_ledger_sequence": 9182734021
}

Note the explicit reserved field — showing the user exactly how much is currently locked in open orders — and the as_of_ledger_sequence field, which ties this balance snapshot to an exact, auditable point in the ledger’s history rather than an ambiguous “current” balance.

13.3 Example — deposit confirmation webhook

POST https://client-integration.example.com/webhooks/deposit
{
  "event": "deposit.confirmed",
  "account_id": "acct_88213",
  "asset": "ETH",
  "amount": "2.35000000",
  "tx_hash": "0x7f9a2e...",
  "confirmations": 32,
  "idempotency_key": "dep_0x7f9a2e_credit"
}

The idempotency_key is derived directly from the on-chain transaction hash, so if the webhook delivery is retried (a common and expected occurrence in distributed systems), the receiving client can safely recognize and ignore the duplicate rather than accidentally processing the same deposit twice on their own side.

14.1 Patterns used

14.2 Idempotency for deposits and withdrawals

Blockchain transactions can be seen multiple times by a node (during reorgs, retries, or duplicate event delivery), so both deposit crediting and withdrawal processing must be idempotent — keyed by the on-chain transaction hash for deposits, and by a unique client-generated withdrawal request ID — ensuring the same blockchain event or client request can never be processed twice.

14.3 Anti-patterns to avoid

15.1 Best practices

15.2 Common mistakes

16.1 Lessons learned across the industry

Studying these incidents reveals a consistent pattern: the exchanges that failed catastrophically almost always had either no reliable reconciliation process, commingled customer and operating funds, or allowed balance-critical code changes to bypass rigorous review. This is precisely why the architecture in this tutorial treats the Ledger Service, Wallet Service, and Reconciliation Service as being just as safety-critical as the matching engine itself — arguably more so, since a matching engine bug loses trust, but a ledger or custody bug can lose actual customer funds.

A second, related pattern worth internalizing: nearly every major exchange failure was, in hindsight, both a technical and an organizational failure. The technical safeguards described throughout this tutorial — double-entry bookkeeping, continuous reconciliation, hot/cold wallet separation, multi-signature approval — only work if the organization actually enforces them without exception, even under pressure to move quickly or cut costs. A reconciliation alert that gets silenced “just this once” during a busy period, or a withdrawal approval step that gets bypassed to resolve an urgent customer complaint, quietly removes the exact safety net the architecture was built to provide. Building the system correctly is necessary but not sufficient — operating it with discipline matters just as much.

17.1 Frequently Asked Questions

17.2 Key Takeaways