How a Crypto Exchange Backend Works: Orders, Balances, Wallets, WebSockets, and Liquidity

CryptoTech — Thu, 08 Oct 2026 05:02:44 +0000

A cryptocurrency exchange may look simple from the outside.

Users see:

A trading chart
Buy and sell forms
An order book
Wallet balances
Deposits and withdrawals But behind that interface is a fairly complex backend system.

A production exchange usually needs to coordinate several independent concerns:

Order matching
Balance management
Wallet operations
Blockchain confirmations
Real-time market data
API access
Liquidity
KYC and AML
P2P trading
Admin operations This article walks through the core backend architecture of a self-hosted cryptocurrency exchange and explains how the pieces fit together.

1. Orders Start With Validation

When a user submits an order, the backend should not send it directly to the matching engine.
First, the request needs to be validated.

For example:

{ "market": "BTC/USDT", "side": "buy", "type": "limit", "price": "67000", "amount": "0.25" }

The backend may need to verify:

The user is authenticated
The market exists
Trading is enabled
The price is valid
The amount is valid
Minimum order requirements are met
The user has enough available balance
Account restrictions do not block trading Only after those checks pass should the order move further into the trading system.

2. Available Balance and Locked Balance Should Be Separate

One of the most important exchange concepts is the difference between available and reserved funds.

Suppose a user has:

Available USDT: 10,000 Locked USDT:

The user creates a buy order requiring 4,000 USDT.

The balance may become:

Available USDT: 6,000 Locked USDT: 4,000

That 4,000 USDT should no longer be available for another order.
Otherwise, two simultaneous requests could attempt to spend the same funds.
This is where database transactions and concurrency control become important.
A simplified transaction might look like:

BEGIN;

SELECT available_balance
FROM balances
WHERE user_id = ?
  AND currency = 'USDT'
FOR UPDATE;

-- validate balance

UPDATE balances
SET available_balance = available_balance - 4000,
    locked_balance = locked_balance + 4000
WHERE user_id = ?;

INSERT INTO orders (...);

COMMIT;

The exact implementation varies, but the core requirement is the same:
funds must not be double-spent inside the exchange database.

3. The Matching Engine Processes the Order Book

Once an order is accepted, it enters the matching process.
Consider this sell-side order book:

67,100 0.40 BTC 67,050 0.30 BTC 67,000 0.50 BTC

A user submits:

BUY 0.60 BTC @ 67,100

The engine can match:

0.50 BTC @ 67,000 0.10 BTC @ 67,050

The incoming order is partially or fully filled depending on available liquidity.

A matching engine typically needs to handle:

Price priority
Time priority
Partial fills
Full fills
Cancellations
Market orders
Limit orders
Multiple markets
Fees
Trade creation

Conceptually:

New Order
   ↓
Validate
   ↓
Reserve Balance
   ↓
Matching Engine
   ↓
Create Trades
   ↓
Update Orders
   ↓
Update Balances
   ↓
Publish Events

4. Trades and Orders Are Different Things

A common modeling mistake is treating an order and a trade as the same object.
They are not.
An order is an instruction.
A trade is an execution.

For example:

Order:
Buy 2 BTC @ 67,000

might produce:

Trade 1:
0.5 BTC @ 66,950

Trade 2:
1.0 BTC @ 66,980

Trade 3:
0.5 BTC @ 67,000

One order can therefore create multiple trades.

A clean database model usually separates:

orders
trades
balances
markets

rather than storing everything in one table.

5. Balance Updates Must Be Atomic

After a trade executes, multiple balances may need to change.
Suppose:

Buyer buys BTC
Seller sells BTC
Trading fees are charged

The system may need to update:

Buyer:
USDT locked ↓
BTC available ↑

Seller:
BTC locked ↓
USDT available ↑

Exchange:
Fee balance ↑

Those operations should be atomic.
You do not want a situation where the buyer receives BTC but the seller does not receive USDT because an error happened halfway through.
Database transactions are essential.

6. Internal Balances Are Not Blockchain Wallet Balances

This is a key architectural distinction.
A trade between two users should not create a blockchain transaction.
Imagine every BTC/USDT trade requiring an actual Bitcoin transaction.
Trading would be extremely slow and expensive.
Instead, exchanges typically maintain an internal ledger.

Blockchain activity happens mainly during:

Deposits
Withdrawals
Wallet consolidation
Treasury operations Trading happens internally.

A simplified structure looks like:

Blockchain
    ↓
Wallet Service
    ↓
Internal Ledger
    ↓
Trading Engine

7. Deposit Processing Is Event Driven

When a user deposits cryptocurrency, the exchange needs to detect the transaction.

A typical flow might be:

Blockchain Transaction
        ↓
Node / Provider Detects Deposit
        ↓
Deposit Service
        ↓
Confirmation Counter
        ↓
Credit User Balance

For example, a deposit record might contain:

{
  "currency": "BTC",
  "txid": "...",
  "amount": "0.50",
  "confirmations": 2,
  "required_confirmations": 3,
  "status": "confirming"
}

Once the confirmation threshold is reached:

status = completed

and the user's internal balance can be credited.

8. Withdrawals Need More Controls Than Deposits

Withdrawals are usually more sensitive because funds are leaving the platform.

A withdrawal flow could look like:

Withdrawal Request
       ↓
Validate Balance
       ↓
Lock Funds
       ↓
2FA / Security Checks
       ↓
Risk Rules
       ↓
Manual or Automatic Approval
       ↓
Wallet Service
       ↓
Blockchain Broadcast
       ↓
Transaction Monitoring

Potential controls include:

2FA
Address whitelist
Daily limits
Manual approval
Risk scoring
Delayed withdrawals
IP checks
Device checks

The wallet system should not be directly exposed to the public web layer.

9. WebSockets Are Essential for Real-Time Trading

REST APIs are useful for actions like:

POST /orders
DELETE /orders/123
GET /wallets
GET /markets

But market data changes constantly.
For real-time data, WebSockets are usually a better fit.

Clients may subscribe to channels such as:

market.BTC_USDT.orderbook
market.BTC_USDT.trades
market.BTC_USDT.ticker
user.123.orders
user.123.balances

When something changes, the backend pushes an event.

Example:

{
  "event": "trade.executed",
  "market": "BTC/USDT",
  "price": "67012.40",
  "amount": "0.08"
}

This avoids repeatedly polling the API.

10. Do Not Put Everything Inside One Request

Imagine a user creates an order.

You probably do not want the API request to also:

Send email
Update analytics
Generate notifications
Sync external liquidity
Write audit reports

Those tasks can be moved to queues.

For example:

Order Executed
      ↓
Dispatch Events
      ↓
Queue
  ├── Notification Worker
  ├── Analytics Worker
  ├── Email Worker
  └── Reporting Worker

This keeps the trading path fast.

11. Liquidity Integrations Need an Adapter Layer

New exchanges often connect to external liquidity providers.
The mistake is tightly coupling the entire application to one provider's API.

Instead, create an abstraction.

For example:

interface LiquidityProvider
{
    public function getTicker(string $market);
    public function getOrderBook(string $market);
    public function placeOrder(array $order);
    public function cancelOrder(string $id);
}

Then create implementations:
BinanceLiquidityProvider
ProviderBLiquidityProvider
InstitutionalProvider

The exchange application talks to the interface rather than directly to one external API.
This makes switching providers much easier.

12. The Same Pattern Works for KYC

KYC providers can also be abstracted.

For example:

interface KycProvider
{
    public function createApplicant($user);
    public function getStatus($externalId);
    public function handleWebhook($payload);
}

Then:

ProviderA ProviderB ManualKycProvider

Internally, your application can use its own statuses:

pending
reviewing
approved
rejected

instead of leaking third-party status formats throughout the entire codebase.

13. P2P Trading Is a Different Domain

P2P trading should usually be modeled separately from the spot matching engine.

A P2P trade may involve:

Offer
Merchant
Buyer
Payment Method
Escrow
Dispute

A simplified flow:

Merchant creates offer
        ↓
Buyer starts transaction
        ↓
Crypto locked in escrow
        ↓
Buyer pays seller
        ↓
Seller confirms payment
        ↓
Crypto released

The main technical challenge is the state machine.

Possible states might include:

created
awaiting_payment
payment_marked
completed
cancelled
disputed

Each transition needs strict rules.

14. The Admin Panel Should Use Role-Based Access

Not every administrator should have the same permissions.

For example:

Super Admin
Compliance Officer
Finance Operator
Support Agent
Market Manager

A support agent may need to view a user account but should probably not be able to approve large withdrawals.

A finance operator may manage withdrawals but should not change system configuration.

Role-based access control becomes more important as the team grows.

15. A Modular Architecture Makes Scaling Easier

A small exchange can begin relatively simply.

For example:

Nginx
  ↓
Application
  ↓
PostgreSQL / MySQL
  ↓
Redis

But as traffic increases, parts of the system can be separated.

                Load Balancer
                     ↓
                API Servers
                     ↓
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
Matching Engine  Wallet Service  User Service
       ↓             ↓             ↓
     Redis       Queue Workers    Database
                     ↓
              Blockchain Nodes

Further services might include:
Liquidity Service
KYC Service
P2P Service
Notification Service
Reporting Service
Market Data Service

The key is not to split everything into microservices from day one.
The key is to define clean boundaries so individual components can be separated later when necessary.

16. Idempotency Matters

Financial systems must be careful with retries.
Suppose an external blockchain provider sends the same deposit webhook twice.

Without idempotency, the exchange might credit the deposit twice.
The same problem can happen with:

Withdrawals
Payment callbacks
KYC callbacks
Order requests
External liquidity updates

A common technique is to store a unique operation identifier.

For example:

yaml
provider: bitcoin
transaction: abc123
output_index: 0

Create a unique database constraint so the same deposit cannot be processed twice.

17. Logging and Audit Trails Are Not Optional

An exchange should be able to answer:

Who approved this withdrawal?
Why was this account suspended?
When was this fee changed?
Which admin changed this market?
What happened to this order?
Which service processed this deposit?

Audit records might look like:

{
  "actor_id": 42,
  "action": "withdrawal.approved",
  "target_id": 9581,
  "timestamp": "2026-10-08T08:44:00Z"
}

Financial software becomes extremely difficult to operate without reliable audit history.

18. Security Should Be Layered

There is no single feature that makes an exchange secure.
Security should exist across the architecture.

Examples:

Authentication
2FA
Session management
Login alerts
Device tracking

APIs
Rate limiting
API keys
Request signing
IP restrictions

Withdrawals
Whitelists
Limits
Manual review
Risk rules

Infrastructure
Firewalls
Monitoring
Secrets management
Restricted SSH access
Backups

Application
Authorization
Input validation
CSRF protection
XSS prevention
SQL injection prevention

Security is a system property, not a checkbox.

19. Why Self-Hosted Source Code Can Matter

A closed SaaS exchange can simplify deployment.

But it also means the vendor controls large parts of the technology.
With a self-hosted platform and source-code access, the operator can potentially:

Change infrastructure
Modify trading behavior
Add blockchains
Replace external providers
Extend APIs
Build custom admin workflows
Add payment systems
Change wallet logic

That becomes increasingly important when the exchange grows beyond the capabilities of the original configuration.

A Simplified Architecture

Putting everything together:

            Web Frontend
            Mobile Apps
            Trading Bots
                 │
                 ▼
        REST + WebSocket API
                 │
     ┌───────────┼────────────┐
     │           │            │
     ▼           ▼            ▼
User Service  Trading      Admin
              Engine
                 │
                 ▼
          Order Management
                 │
                 ▼
          Balance / Ledger
             │       │
             │       │
             ▼       ▼
          Wallet   Liquidity
          Service   Service
             │       │
             ▼       ▼
        Blockchains  Providers

Around those services:

KYC / AML
P2P
Notifications
Queues
Monitoring
Reporting
Payment Gateways

That is much closer to what a real cryptocurrency exchange backend looks like than a single monolithic "trading script."
How We Approach This at CryptoTech

At CryptoTech, we build commercial cryptocurrency exchange software around a self-hosted, full-source model.

The platform can include:

Matching engine
Real-time order books
Multi-currency wallets
Admin panel
KYC and AML integrations
P2P trading
Liquidity connectivity
REST and WebSocket APIs
Mobile applications
Self-hosted deployment

The main idea is that customers can start with an existing exchange foundation while retaining the ability to customize the platform at the source-code level.

If you want to see the product architecture from the commercial side:

Crypto Exchange Source Code:

cryptotech.exchange/crypto-exchange-source-code

CryptoTech:
cryptotech.exchange

Live Demo:
demo.cryptotech.exchange

Final Thoughts

A cryptocurrency exchange backend is mostly about maintaining consistency across multiple systems.

The difficult parts are not the trading buttons.

They are:

- Preventing double spending
- Keeping balances correct
- Matching orders reliably
- Synchronizing real-time data
- Processing blockchain events safely
- Handling retries
- Managing external integrations
- Keeping audit trails
- Controlling permissions
- Scaling without breaking financial consistency

If those foundations are designed well, the frontend becomes the easy part.

If they are designed poorly, no amount of UI polish will make the exchange reliable.

DEV Community: CryptoTech

How a Crypto Exchange Backend Works: Orders, Balances, Wallets, WebSockets, and Liquidity

1. Orders Start With Validation

2. Available Balance and Locked Balance Should Be Separate

3. The Matching Engine Processes the Order Book

4. Trades and Orders Are Different Things

5. Balance Updates Must Be Atomic

6. Internal Balances Are Not Blockchain Wallet Balances

7. Deposit Processing Is Event Driven

8. Withdrawals Need More Controls Than Deposits

9. WebSockets Are Essential for Real-Time Trading

10. Do Not Put Everything Inside One Request

11. Liquidity Integrations Need an Adapter Layer

12. The Same Pattern Works for KYC

13. P2P Trading Is a Different Domain

14. The Admin Panel Should Use Role-Based Access

15. A Modular Architecture Makes Scaling Easier

16. Idempotency Matters

17. Logging and Audit Trails Are Not Optional

18. Security Should Be Layered

19. Why Self-Hosted Source Code Can Matter

Final Thoughts