I built a C++ options execution and back testing engine with Black-Scholes. Looking for feedback on my concurrency model and memory layout.

Hi everyone,


I recently built a C++ options execution and backtesting engine utilizing Black-Scholes pricing, walk-forward optimization, and regime-based strategy selection. It's fully wired to execute paper/live trades via Alpaca.


I'm looking for harsh, constructive feedback on my architecture—specifically regarding my order ledger concurrency model and C++ memory layout.


Specific areas I'd love feedback on:
1. Concurrency in "Orderledger":
I opted for standard `std::mutex` and `std::atomic` flags rather than a lock-free queue for position state management. I'm prioritizing preventing "ghost fills" over sub-millisecond latency. Did I make the right trade-off here, and are there any glaring race conditions I missed?
2. Memory Layout:
I’m relying on standard containers (`std::vector`, `std::unordered_map`) but minimizing dynamic heap allocations on the critical path. Are there better patterns I should adopt to avoid OS allocator pauses during market hours?
3.
Black-Scholes Math Precision:
I used standard `double` precision and `std::erfc` rather than fast-math approximations to ensure numerical stability when calculating Greeks like Gamma on short-dated options.


Here is the repo: github.com/kdyn-ctrl/Nox


If you want to see the rationale behind my decisions, check out `docs/guides/DESIGN_THINKING.md` in the repository.
I also have journals of my work and guides if any other info is needed. I'm still quite novice so please be as harsh as you can I'm really trying to improve.


Thanks in advance for your time and feedback!

https://redd.it/1v7v4ev
@r_cpp