รูปแบบการออกแบบซอฟต์แวร์สำหรับระบบเทรด

ซอฟต์แวร์การเงินล้มเหลวในรูปแบบที่มีค่าใช้จ่ายสูง: คำสั่งซ้ำ ยอดคงเหลือที่ไม่สอดคล้องกัน ความล้มเหลวบางส่วนที่เงียบเชียบ Design pattern ไม่ใช่ถ้วยรางวัล — มันคือคำตอบต่อรูปแบบความล้มเหลวที่เกิดซ้ำ ๆ: event sourcing เพื่อการตรวจสอบได้ CQRS เพื่อขยายฝั่งอ่านให้แตกต่างจากฝั่งเขียน circuit breaker เพื่อหยุดการล่มที่ลุกลาม และ idempotency เพื่อให้การ retry ไม่ทำให้เกิดการเทรดซ้ำสอง

เอนจินจับคู่คำสั่ง (matching engine) การตรวจสอบความเสี่ยง และผู้เผยแพร่ข้อมูลตลาดไม่ควรเรียกกันโดยตรงจนกลายเป็นก้อนโค้ดพันกันยุ่งเหยิง บัส publish/subscribe ให้ matcher ปล่อย fill ออกมาในขณะที่บริการปลายทางสมัครรับได้โดยไม่ต้องรู้รายละเอียดการทำงานภายในของฝั่งต้นทาง — แต่คุณยังต้องเลือกการันตีการส่งมอบ (at-least-once เทียบกับ exactly-once) และระยะเวลาเก็บข้อมูลสำหรับการ replay

Circuit breaker หยุดการเรียกใช้ dependency ที่มีปัญหาหลังจากล้มเหลวซ้ำ ๆ ให้เวลามันฟื้นตัวและปกป้อง thread pool ของคุณ Bulkhead แยก pool ของทรัพยากรออกจากกัน เพื่อไม่ให้งาน analytics ที่ควบคุมไม่ได้ไปแย่งทรัพยากรจนการส่งคำสั่งเทรดขาดแคลน

คำสั่งเทรดและการโอนมีวงจรชีวิตที่มีเงื่อนไข เข้ารหัสการเปลี่ยนสถานะที่อนุญาตไว้ใน finite state machine เพื่อให้การกระโดดสถานะที่ไม่ถูกต้องเป็นไปไม่ได้ จับคู่กับ idempotency key บนคำขอของไคลเอนต์ เพื่อไม่ให้การ retry บนเครือข่ายสร้างคำสั่งที่ทำงานซ้ำขึ้นมาสองชุด

เวทีเทรดแบบรวมศูนย์จับคู่คำสั่งที่เข้ามากับสภาพคล่องที่พักรออยู่ตามลำดับความสำคัญของราคาและเวลา (price-time priority) ตัวจับคู่บนเชน (เหมือนที่ L1 DEX หลายรายออกแบบไว้) ต้องมีความแน่นอนเชิงกำหนด (deterministic): validator ทุกตัวรันลำดับเดียวกันซ้ำและได้ state เดียวกันเป๊ะ — GaiaEx รับโมเดลนี้มาจากกฎของ Hyperliquid

อย่าลอกทุก pattern มาใช้ตั้งแต่วันแรกโดยไม่คิด เริ่มจากขอบเขตที่ชัดเจน log ที่มีโครงสร้าง และการทดสอบรอบ ๆ การเคลื่อนย้ายเงิน เพิ่ม event log เมื่อความปวดหัวจากการกระทบยอดปรากฏขึ้น เพิ่ม circuit breaker เมื่อ API ภายนอกเริ่มไม่มั่นคง Pattern แก้ปัญหาที่เกิดขึ้นจริง ไม่ใช่ปัญหาที่จินตนาการขึ้นมา