
Design Pattern Software Engineering untuk Sistem Trading
Event sourcing, CQRS, dan pola arsitektur yang dipakai exchange
Mengapa Pattern Penting dalam Sistem Trading
Software finansial gagal dengan cara yang mahal: order duplikat, saldo yang tidak konsisten, kegagalan parsial yang senyap. Design pattern bukanlah trofi — mereka adalah respons terhadap mode kegagalan yang berulang: event sourcing untuk auditabilitas, CQRS untuk menskalakan pembacaan secara berbeda dari penulisan, circuit breaker untuk menghentikan gangguan yang merambat, dan idempotency sehingga retry tidak menghasilkan trading ganda.
Pub/Sub dan Loose Coupling
Matching engine, pengecekan risiko, dan publisher data market seharusnya tidak saling memanggil langsung dalam sebuah gumpalan lumpur raksasa. Sebuah bus publish/subscribe memungkinkan matcher mengeluarkan fill sementara layanan hilir bisa subscribe tanpa perlu tahu detail implementasi layanan hulunya — tapi kamu tetap harus memilih garansi pengiriman (at-least-once vs exactly-once) dan retensi untuk replay.
Circuit Breaker dan Bulkhead
Sebuah circuit breaker menghentikan pemanggilan sebuah dependency yang bermasalah setelah kegagalan berulang, memberinya waktu untuk pulih dan melindungi thread pool-mu. Bulkhead mengisolasi resource pool sehingga sebuah job analitik yang lepas kendali tidak bisa membuat kelaparan proses pengiriman order.
State Machine dan Idempotency
Order dan transfer punya siklus hidup yang sah. Kodekan transisi yang diperbolehkan dalam sebuah finite state machine sehingga lompatan yang tidak valid menjadi mustahil. Padukan itu dengan idempotency key pada permintaan client sehingga retry jaringan tidak bisa menciptakan order live yang duplikat.
Matching Engine: Price-Time Priority
Platform terpusat mencocokkan order yang masuk dengan likuiditas yang mengendap berdasarkan price-time priority (prioritas harga-waktu). Matcher on-chain (seperti banyak desain DEX L1) harus deterministik: setiap validator menjalankan ulang urutan yang sama dan mencapai state yang identik — GaiaEx mewarisi model ini dari aturan Hyperliquid.
Adopsi yang Pragmatis
Jangan cargo-cult semua pattern di hari pertama. Mulai dengan batasan yang jelas, log yang terstruktur, dan test di sekitar perpindahan uang. Tambahkan sebuah event log ketika rasa sakit rekonsiliasi muncul; tambahkan circuit breaker ketika API eksternal mulai tidak stabil. Pattern menyelesaikan masalah nyata, bukan masalah imajiner.