Minute
A crypto derivatives exchange for India. I’m the technical co-founder.
- Where
- Independent
- Status
- In development
- My part
- Architecture and code across the exchange.
- Built with
- Rust, Go, TypeScript, PostgreSQL, Kafka, Redis
Minute isn’t live with real money yet. Cryptathon already runs on its infrastructure with virtual money.
I work across order processing, matching, market data, wallets, and positions. Matching is in Rust, market data is in Go, and the services around them are TypeScript.
Keeping state consistent
Most of the hard questions are about state. When should funds be reserved? What happens if an event is delivered twice? How do the order, the fill, the wallet, and the position stay in agreement when one step fails?
Where 82.77 ms went
Trace from
I traced one order through admission: validation, the risk check, reserving funds, saving it, and publishing it to Kafka.
| Stage | Share | Milliseconds |
|---|---|---|
| Validation, metadata, first transaction | 13.13 | |
| Pre-trade risk check | 7.23 | |
| Reserving funds in the wallet | 33.52 | |
| Second transaction, outbox claim | 17.26 | |
| Publishing to Kafka | 9.74 | |
| Everything else | 1.89 | |
| Total | 82.77 ms |
Reserving funds was about 40% of the total, more than the risk check and Kafka combined.
So that’s where I’m looking next, before touching the matching loop. Whatever changes, the reservation still has to stop the same money from being spent twice.
One trace, not a benchmark.