<aside> 🛠 There is a GitHub repository associated with this document, which shows a work in progress implement of the design outlined in this document!

</aside>

I previously wrote a "toy" implementation of a crypto trading bot: it streamed market data from an exchange, transformed the payloads to a pandas.Dataframe and piped it through to a user defined "strategy" - an object that could apply computations to the incoming data and determine whether or not an action was required. Sounds cool, but it was a toy.

Well, over dinner recently I was asked whether I'd given anymore thought to that project, and - after thinking "hah, I can lose money in much more enjoyable ways" - I realised it would be pretty interesting to think about how to refactor and productionise it.

Requirements

Behind the complexity of actual trading logic, the functional requirements are pretty simple - and they also lead quite naturally to a nice and simple design.

1. The system should be able to subscribe to a stream of market data;
2. transformations should be applied to this stream of inbound data;
3. there must be an interface for sending orders to the exchange;
4. the interface for handling exchange interactions - such as placing orders, transforming data, and subscribing to streams - should be common amongst any supported exchanges;
5. balances and positions for the current account need to be monitored for performing risk calculations and determine whether trades are possible or acceptable.

A note about strategy

This system doesn't care about what strategy you want to run in it. All it knows about the strategy is that it wants market data of a given format, and it needs to be able to handle making buy/sell calls.

<aside> 🎯 I have very little domain knowledge - the knowledge I do have comes from reading a couple of books, and browsing MOOC content out of curiosity. This is yet another reason for not bike-shedding on strategy.

</aside>

High Level Architecture

This design contains 3 components, all with clear responsibilities - and although the Strategy component may at first appear to be "doing too much", it's design is to allow the end-user to completely customise as much of the system as they want.

API Adapter

The API Adapter can be viewed as a transformational proxy with some connection management logic thrown in - i.e. retry attempts with exponential backoff, PING/PONG messages and reconnection for websocket streams.