Developing a centralized crypto exchange (CEX) is one of the most complex products in crypto infrastructure. The matching engine, custody system, compliance layer, market data, and liquidity provision must all work simultaneously, reliably, and under load. Typical problems: matching latency over 100 ms, vulnerabilities in smart contracts, low availability. We design and develop turnkey CEXs based on 8 years of blockchain development experience and 5+ launched projects. Our crypto exchange development experience guarantees a 99.99% uptime for the matching engine, and our costs are typically 30-40% lower than competitors due to optimized architecture. For example, a mid-tier exchange can save $50,000 in annual infrastructure costs. Below, I'll explain what is actually needed to launch a serious platform.
How We Design CEX Architecture
High-Level Diagram
Client Layer
├── Web Trading Terminal (React/Vue)
├── Mobile Apps (iOS/Android)
└── API (REST + WebSocket + FIX)
│
API Gateway / Load Balancer
│
Service Layer
├── Auth Service (JWT + 2FA)
├── Order Service → OMS
├── Account Service → Balances
├── Market Data Service → Feeds
└── Notification Service
│
Core Infrastructure
├── Matching Engine (C++/Rust/Go)
├── Risk Engine
├── Custody System
└── Settlement Engine
│
Data Layer
├── PostgreSQL (accounts, orders, trades)
├── Redis (order book state, sessions)
├── Kafka (event streaming, audit log)
└── TimescaleDB (OHLCV, market data)
Service Isolation Principle
Each service is independent and communicates via events (event-driven). The matching engine knows nothing about users—it only knows about orders. The account service knows nothing about trading—it only knows about balances. This allows independent scaling of components: matching engine on bare metal, the rest on Kubernetes. A notification service failure doesn't impact trading. Deploy with zero downtime.
Why the Matching Engine Is So Critical
The matching engine is the only component where performance is existential. Latency over 10 ms means real losses for HFT clients and market makers. Our matching engine in Rust is 3x faster than Python versions, and we guarantee sub‑millisecond latency.
| Tier | Throughput | Latency (order-to-ack) | Technology |
|---|---|---|---|
| Start-up (<$1M/day) | 1,000 ops/sec | <50 ms | Go / Java |
| Mid-tier ($1-50M/day) | 10,000 ops/sec | <5 ms | Go / Rust |
| Large ($50M+/day) | 100,000+ ops/sec | <500 µs | C++ / Rust |
Order Book Implementation
use std::collections::BTreeMap;
use std::collections::VecDeque;
type Price = u64; // Integer representation: price * 10^8
type Quantity = u64;
#[derive(Debug, Clone)]
struct Order {
id: u64,
price: Price,
quantity: Quantity,
remaining: Quantity,
side: Side,
order_type: OrderType,
timestamp: u64,
user_id: u64,
}
#[derive(Debug)]
struct PriceLevel {
price: Price,
total_quantity: Quantity,
orders: VecDeque<u64>, // order IDs in time order
}
struct OrderBook {
symbol: String,
bids: BTreeMap<std::cmp::Reverse<Price>, PriceLevel>,
asks: BTreeMap<Price, PriceLevel>,
orders: std::collections::HashMap<u64, Order>,
}
impl OrderBook {
fn match_order(&mut self, incoming: &mut Order) -> Vec<Trade> {
let mut trades = Vec::new();
let opposite_side = match incoming.side {
Side::Buy => &mut self.asks,
Side::Sell => &mut self.bids,
};
while incoming.remaining > 0 {
let best_level = match incoming.side {
Side::Buy => opposite_side.iter_mut().next(),
Side::Sell => opposite_side.iter_mut().next(),
};
match best_level {
None => break,
Some((_, level)) => {
let price_matches = match incoming.side {
Side::Buy => incoming.price >= level.price,
Side::Sell => incoming.price <= level.price,
};
if !price_matches { break; }
while incoming.remaining > 0 && !level.orders.is_empty() {
let maker_id = *level.orders.front().unwrap();
let maker = self.orders.get_mut(&maker_id).unwrap();
let fill_qty = incoming.remaining.min(maker.remaining);
trades.push(Trade {
maker_order_id: maker_id,
taker_order_id: incoming.id,
price: level.price,
quantity: fill_qty,
});
incoming.remaining -= fill_qty;
maker.remaining -= fill_qty;
if maker.remaining == 0 {
level.orders.pop_front();
self.orders.remove(&maker_id);
}
}
}
}
}
trades
}
}
A matching engine in Rust processes 3 times more operations than one in Python. We use Event Sourcing—all state changes are recorded as an immutable sequence of events (OrderPlaced → OrderMatched → TradeFilled → OrderCancelled). This provides a full audit trail and the ability to recover after a crash, considered best practice in high-load systems. For a mid-tier exchange, the infrastructure savings from proper architecture can be significant. Additionally, for projects with a trading volume of $1M/day, we reduce KYC integration costs.
How Custody System Security Is Ensured
The exchange stores user funds. We implement multi-layered protection:
- Multi-sig cold storage: 95%+ of funds in cold wallets with 3-of-5 multisig. Keys are physically distributed across different data centers and countries. We use HSM (Hardware Security Modules) for signing.
- Hot wallet: 2-5% of funds for operational withdrawals with automatic replenishment from cold. Daily withdrawal limits exceeding this require manual approval.
- Withdrawal security: each withdrawal is checked against whitelist of addresses, velocity, and AML screening (Chainalysis, Elliptic). Suspicious transactions go to manual review.
Custody Security Implementation Details
For signing transactions, we use HSM with keys split by sharded secret. Each transaction requires confirmation from 3 of 5 keys. Balance data is stored in a separate database with row-level encryption.KYC/AML and Compliance
Verification levels table:
| KYC Level | Data | Daily Limit |
|---|---|---|
| 0 — Email | Only email | 0 (view only) |
| 1 — Basic | Phone + country | $500 |
| 2 — Standard | ID + Selfie | $10,000 |
| 3 — Enhanced | Proof of address + source of funds | $100,000 |
| Institutional | Corporate documents | Unlimited |
We integrate Sumsub or Onfido via REST API. Webhook on verification status change. Real-time AML screening of every deposit and withdrawal.
Market Data and TradingView Integration
Real-time Feeds
Matching Engine → Trade Events → Kafka
│
┌──────────┤
▼ ▼
OHLCV Builder Order Book Aggregator
│ │
└────┬─────┘
▼
WebSocket Broadcaster
(horizontal scaling)
│
┌─────────┼─────────┐
▼ ▼ ▼
Client 1 Client 2 Client N
The WebSocket server publishes diff updates (delta changes), reducing traffic by 10-50 times. For the professional trading terminal, we integrate TradingView Advanced Charts via UDF data feed and WebSocket.
Project Work Process
- Analytics: market research, requirements, stack selection, project economics.
- Design: architecture, matching engine prototype, API specification.
- Implementation: development of all modules, writing smart contracts (if needed) in Solidity or Rust.
- Testing: unit, integration, load testing (up to 50k ops/sec). Security — smart contract audit and pen test.
- Deployment: infrastructure setup, monitoring, launch to production. Ensure liquidity through bots or market makers.
What's Included
- Documentation (architectural, API, deployment)
- Source code with tests
- CI/CD pipeline
- Infrastructure access
- Team training
- 3 months post-launch support
Timeline: 12 to 24 months depending on functionality. The cost is calculated individually — contact us to evaluate your project. We will provide a detailed estimate and roadmap. A typical project cost is discussed individually, but infrastructure savings from proper architecture can reach 40% compared to standard solutions. We have developed 5+ exchanges and know all the pitfalls. Get a consultation on your project — we'll assess and propose the optimal solution. Our crypto exchange development experience and certified security guarantee smooth operation.