Scalable stock trading infrastructure designed for use by algos
- Communication with multiple brokers, e.g. TdAmeritrade, Kraken
- Multiple connections to the same broker as needed
- Resources added as needed to handle increased load
- Brokers can change behind the scenes without impacting algos
- Designed with high availability in mind
- REST & WebSocket API
- Broker – a broker such as tdameritrade or kraken
- Market – used to interact with exchanges without knowing which api is actually used behind the scenes
- Trader – a stock trading algo, a bot which automates stock trading algorithms
- BrokerManager – able to spin up & spin down brokers, provides status
- MarketManager – able to spin up & spin down markets, provides status
- TraderManager – able to spin up & spin down traders, provides status
- InfrastructureManager – overall status display & interaction with all Managers
- Each service implemented with c# using combination of REST & WebSocket
- Distributed implementation
- At each location where a duplicate implementation exists, there will be the three managers.
- A location may have more than one implementation.
- A new implementation may be spun up at any time as demand requires
- An unused implementation may be flagged to no longer allow new connections and dropped afterhours
- Infrastructure Management
- As managers are spun up they check-in with one or more InfrastructureManager(s) which provide an overall view of the whole infrastructure
- Managers can be checked for status and monitored via WebSocket for status
- Once connected, a customer algo will have access to a MarketManager
- Upon disconnection & reconnect, a customer algo will again have access to a MarketManager, but the actual servers may be different.
- For interacting with traders a customer can manage their own traders, or use a TraderManager. TraderManager(s) can be spawned as needed, but a customer will need to be able to use the same TraderManger for each of his Traders to connect with.
- Traders, Markets, Brokers, upon being spawned, will checkin with their respective Manager via REST.
- The respective Manager then will establish a WebSocket connection with the spawned service. This will be the pipe used for two-way communcation.
- All dropped WebSocket connections are to be re-established by the party who originally created the WebSocket connection.
Initial development phase