August Takeaways
Some takeaways I've had from building an exchange in c++ for Quantitative Finance UWA.
This was my first multi-week C++ project.
BRAIN DUMP:
- Serialisation and data model are hard
- Djimon and I spent a while determining what the core types should be
- the shape of the system rises from the structure of the data
- for example, in a previous system, a cancel order was implemented by sending negative quantity to cancel an order
- this choice for meant cancel orders could have race issues, since cancelling an order that had already been traded led to you placing an order on the market
- difficult to implement idempotency (trying to cancel an order with no response meant you were adding multiple of the opposite order)
- included cancel order and new order as the new core types
- unsure how to model commands that act on hierarchical structures
- the internal representation of an exchange was:
- exchange has many symbols has (bid, ask)
- passing down a new order to the bid and asks meant exposing functions in the exchange interface - it led to the interface becoming very bloated and verbose
- I don't think this was ideal since it violates the single responsibility principle
- going to update so that commands either act on that class, or can get a reference to the class they want
- creating a serialisation layer
- the frontend and backend prefer data to be structured in different ways
- frontend prefers normalised data (unsure about this but this was how we approached it)
- backend wants to go fast, and doesn't want to have to do unnecessary searches to get the data it wants.
- Ideal vs Working
- responsibility for exchange class is data feed, order management and authorisation. this is not ideal, however to get to a working state, we cut some corners.
- support the core functionality first, and get it working correctly, before moving on to the nice to haves
What would I do different?
- I'm not sure yet :3