
Mẫu thiết kế kỹ thuật phần mềm cho hệ thống giao dịch
Event sourcing, CQRS, và các mẫu kiến trúc mà sàn giao dịch sử dụng
Vì sao design pattern quan trọng trong hệ thống giao dịch
Phần mềm tài chính thất bại theo những cách rất đắt giá: lệnh trùng lặp, số dư không nhất quán, lỗi cục bộ âm thầm. Design pattern không phải là chiến tích để khoe — chúng là câu trả lời cho các kiểu lỗi lặp lại: event sourcing cho khả năng kiểm toán, CQRS để mở rộng đọc khác với viết, circuit breaker để chặn sự cố lan chuỗi, và idempotency để việc retry không tạo giao dịch nhân đôi.
Pub/Sub và sự kết nối lỏng
Matching engine, kiểm tra rủi ro, và bộ phát dữ liệu thị trường không nên gọi trực tiếp lẫn nhau tạo thành một mớ bùi nhùi khổng lồ. Một hệ thống publish/subscribe cho phép bộ khớp lệnh phát ra các lần khớp trong khi các dịch vụ downstream đăng ký (subscribe) mà không cần biết chi tiết triển khai của các bên upstream — nhưng bạn vẫn phải chọn mức đảm bảo phân phát (ít nhất một lần vs chính xác một lần) và thời gian lưu giữ để phát lại.
Circuit breaker và bulkhead
Một circuit breaker ngừng gọi một phụ thuộc đang gặp sự cố sau nhiều lần thất bại liên tiếp, cho nó thời gian hồi phục và bảo vệ thread pool của bạn. Bulkhead cô lập các pool tài nguyên để một tác vụ phân tích chạy mất kiểm soát không thể làm cạn kiệt tài nguyên của việc gửi lệnh.
Máy trạng thái và idempotency
Lệnh và chuyển tiền có chu trình sống hợp lệ theo quy tắc. Hãy mã hóa các bước chuyển trạng thái được phép trong một máy trạng thái hữu hạn để các bước nhảy không hợp lệ trở nên bất khả thi. Kết hợp điều đó với idempotency key trên các yêu cầu của client để việc retry qua mạng không thể tạo ra lệnh trùng lặp đang chạy.
Matching engine: ưu tiên theo giá-thời gian
Các sàn tập trung khớp các lệnh đến với thanh khoản đang chờ theo nguyên tắc ưu tiên giá-thời gian. Các bộ khớp lệnh trên chuỗi (như nhiều thiết kế DEX L1) phải mang tính xác định: mọi validator thực thi lại cùng một chuỗi thao tác và đạt được cùng trạng thái — GaiaEx thừa hưởng mô hình này từ các quy tắc của Hyperliquid.
Áp dụng thực tế
Đừng áp dụng mọi pattern một cách rập khuôn ngay từ ngày đầu. Hãy bắt đầu với ranh giới rõ ràng, log có cấu trúc, và các bài test xung quanh việc chuyển tiền. Thêm event log khi xuất hiện khó khăn trong việc đối soát; thêm circuit breaker khi các API bên ngoài hoạt động chập chờn. Pattern giải quyết những vết trầy xước thực sự, không phải những thứ tưởng tượng.