A complete refactor

This is becoming a bit of a trademark for my personal projects (but imo, not for no good reason). In fact, building the bot in rust was on my mind since the beginning but I was under the (false) impression that I could only work with it once the rust ibapi library was completely asynchronous or I wouldn't see any improvements. However, one day, while showering, I was wondering how exactly I would implement the bot in Rust without an asynchronous client and realised that most of the interfacing with IBKR would be synchronous for each strategy anyway (with each strategy on a different thread).

Honestly, this was probably the best choice I made for the bot so far - on one hand, static typing and Rust's insane compiler made bugs so much easier to catch. On the other hand, not using a third party extension (i.e. ib_async) that obfuscated the underlying calls made the underlying architecture a lot more intuitive. Whereby in ib_async, there were global events attached to the client for which one had no idea when was triggered, in rust ibapi, every subscription was crystal clear and you knew exactly how and what you would get through various subscriptions and how to listen for the event you want. This drove an overhaul for how the whole bot worked as well - whereby previously i tried to listen to events after placing orders for strategies, I now have a unified Order Management System that listens to all the order events and updates everything acordingly.

Order Engine:

Order Engine Architecture

Furthermore, I have a Consolidator struct that easily abstracts subscriptions for contracts and re-subscribes in case data goes stale - the trigger for each strategy subscription is also therefore, unified for conflicting contracts and no additional unecessary subscriptions to the same contract is made.

Consolidator:

Consolidator Architecture

Final Architecture

The following showcases the flow of updates in the program with the key table definitions.

Flow

Honestly, because of these changes, one could easily assume the bot did not require much work on first glance - everything is much cleaner and the logic isn't too sophisticated. Yet, I took roughly a full month of full dedication to get this up and stable - several iterations including obsolete code due to new DB triggers, several minor updates to the database schema over time and ensuring that I am mostly using the right structures (like synchronous Mutexes or tokio Mutexes, ...) or ensuring infinite loops are spun up in a new OS kernel thread (rather than a new tokio thread), .... All this won't be seen because the repo that I will eventually make public will be the skeleton, not including any of the strategies I am currently testing out.

Find the project here