Nexus risk engine / Systems
Concurrency where correctness comes first.
Engineering the concurrency architecture of a risk engine for a verifiable spot and perpetual-futures exchange.
- My role
- Backend / Systems Engineer
- When
- May 2026 — present
- Built with
- Rust · Concurrency · Risk systems · Observability
Explore how it works
Try it yourself ↓A check is not a reservation.
Send the same orders through two admission strategies.
Ready. Independent checks all read the same starting balance.
An illustrative model of collateral reservation, not the production risk engine. Concurrent independent checks are modeled against one shared starting balance.
The challenge
An order can be valid in isolation and still overcommit an account when other orders arrive at the same time. The risk engine needs to reserve margin atomically, account for existing positions, and keep contention visible as throughput grows.
How I built it
Reserve before accepting
I implemented atomic pre-trade margin reservations and position-aware checks to prevent concurrent orders from committing more margin than an account can support.
Make contention measurable
I optimized lock acquisition and added per-domain lock-wait metrics so that synchronization costs could be inspected and improved.
Protect the reference price
I hardened mark-price oracles with volume-weighted trade blending and snapshot-restore validation, and introduced TTL-cached admin endpoints for observability.
What came out of it
Lock-acquisition improvements recovered 15–31% throughput. Cached admin responses were 76× faster on cache hits. These measurements apply to the individual engineering changes.
The interactive explanation uses illustrative values and is not the production risk engine.