ENVI

Thiết kế exchange-core — Phần 1: Tổng quan & các thành phần cơ bản

23 tháng 5, 2026

Mở đầu series về thiết kế exchange-core cho sàn giao dịch crypto/stock — phần 1 mô tả chức năng tổng thể và các thành phần cơ bản nhất của một sàn.

Thiết kế exchange-core — Phần 1: Tổng quan & các thành phần cơ bản

Đây là phần đầu trong series "Thiết kế exchange-core" — nơi mình ghi lại quá trình build core của một sàn giao dịch (crypto hoặc stock) từ những version đơn giản nhất, rồi dần tối ưu lên.

1. Exchange-core làm gì?

Một exchange-core có một nhiệm vụ duy nhất: giúp người mua và người bán gặp nhau và khớp lệnh một cách công bằng, nhanh chóng, và chính xác.

Một vòng đời cơ bản của một lệnh trông như sau:

  1. User gửi một order (mua hoặc bán) đến sàn.
  2. Sàn validate order (định dạng, quyền, số dư...).
  3. Sàn chạy risk check (user có vượt hạn mức không, có đủ tiền không...).
  4. Order được đưa vào matching engine để khớp với các lệnh buy/sell.
  5. Nếu khớp được → sinh ra execution (fill hoặc nhiều người gọi là trade), cập nhật balance của hai bên.
  6. Cập nhật order book, trade history, candlestick...
  7. Phát thông tin đó ra cho client qua WebSocket / stream.

Tất cả các bước trên phải nhất quán: không được để một lệnh khớp hai lần, không được cho user dùng tiền họ không có, và không được phát ra cho người này thấy giá khác người kia.

2. Các thành phần cơ bản

Ở version đơn giản nhất, một exchange-core sẽ gồm chuỗi component sau:

Client → API Gateway → Risk + Validate → Matching Engine → Order Book
                                              │
                                              ▼
                                       WS / Data Stream → Client

Mỗi component giữ một trách nhiệm rõ ràng. Chúng ta có thể dùng microservice, hoặc để tối ưu, giảm latency, ta có thể dùng chung 1 process.

2.1. API Gateway

Là entrypoint duy nhất mà client (web, app, bot, broker) tương tác. Trách nhiệm chính: Authentication, Input validation, Rate limiting, Normalization

Nguyên tắc: gateway phải nhẹ và nhanh. Mọi logic nghiệp vụ nặng đều được đẩy xuống tầng dưới.

2.2. Risk + Validate Check

Đây là tầng quyết định có cho order này đi tiếp hay không: Check balance, risk check, pre-trade validation.

Nếu fail bất kỳ check nào, order bị reject ngay tại đây, không xuống tới matching engine.

2.3. Matching Engine

Đây là trái tim của exchange-core. Nhận order đã được validate, và làm đúng một việc: khớp lệnh.

  • Duy trì order book cho mỗi symbol (BTC/USDT, ETH/USDT...).
  • Khi có order mới: tìm các lệnh đối ứng trong order book có giá phù hợp.
  • Mỗi lần match sinh ra 2 execution (một cho buy side, một cho sell side).
  • Nếu không khớp hết → phần còn lại nằm lại trong order book chờ.

Một matching engine tốt phải deterministic: cùng một chuỗi order vào, replay sẽ ra đúng cùng một chuỗi execution. Điều này cực kỳ quan trọng cho recovery và replication.

2.4. Order Book

Order book là cấu trúc dữ liệu quan trọng nhất bên trong matching engine. Nó là danh sách tất cả lệnh limit đang chờ khớp cho một symbol.

Một orderbook tốt là một orderbook lưu trữ data đúng và hiệu quả cho việc search, insert, update, delete.

2.5. WebSocket / Data Stream

Mỗi khi có execution, order book thay đổi, hay nến đóng, sàn phải đẩy thông tin đó ra cho client realtime:

  • Trade stream: các lệnh vừa khớp.
  • Order book stream: snapshot + delta của order book (L1/L2/L3).
  • Candlestick stream: nến theo các khung thời gian (1m, 5m, 1h...).
  • User stream: trạng thái order của riêng user (filled, canceled, partially filled), cập nhật balance.

Tầng này thường được tách thành một service riêng (market data publisher) để không làm chậm matching engine — matching engine chỉ cần phát event ra, ai cần thì subscribe.

3. Đó là tất cả… ở version cơ bản

Với 5 component trên, ta đã có thể build một sàn chạy được — đủ cho vài chục user, vài symbol, vài trăm order/giây.

Nhưng ngay lập tức sẽ gặp một loạt câu hỏi khó:

  • Nếu hàng chục nghìn user cùng đặt lệnh trong một giây thì matching engine xử lý kiểu gì? Lock? Single-thread?
  • Nếu sàn có hàng nghìn symbol thì một matching engine có gánh nổi không? Shard kiểu gì?
  • Làm sao để latency p99 ở mức micro-giây, không phải milli-giây?
  • Sàn sập giữa phiên thì recover ra sao mà không mất / không khớp sai lệnh nào?
  • Làm sao để deterministic replay được toàn bộ phiên giao dịch?
  • Wallet và matching engine đặt ở đâu để vừa nhanh vừa an toàn về tiền?

Mỗi câu hỏi sẽ đem tới rất nhiều thách thức và yêu cầu nâng cấp và tối ưu cho dev. Chúng ta sẽ nói về chúng ở những post tiếp theo.