Cloud Trade Copier

The Cloud Trade Copier is a cloud based Binary Options Trading System system where Signal Providers send signals to the service using a web based interface. When a signal arrives, all the subscribers to that signal are gathered from a Redis in-memory key-value store. Per user we check which broker they use and send the signal to other microservices (one or more per broker) that will send the purchase transaction to the broker's server.

The front end website is a responsive design built using Vue.js and Bootstrap. It's used for generating signals and gives the Signal Provider feedback on this performance and his customers. The system has its own subscription system where end-users can subscribe and join the channels of Signal Providers. The front end is stateless and uses JWT (Jason Web Tokens) for authentication and authorisation. It's role-based where Signal Providers can designate other traders to send signals on their behalf. The front end is a static site hosted on AWS S3 buckets and uses AWS CloudFront as its Content Delivery Network.

The backend consists of a collection of loosely coupled micro-services using node.js as the run-time. In Options Trading, fast execution speed and low latency is the most important feature. By implementing all functions as micro-services that can run in parallel on different servers we can simply scale horizontally to keep the total throughput under the required one second, no matter how many users the system has to trade for. We just add more instances of services. The main service will receive signals via a websockets interface and add every user who subscribed to the signal to a Redis in-memory queue. The users are also stored in the same Redis database for ultra-fast retrieval. When all applicable users are added to the queue, the service will send a message via websockets to all broker services. Upon the reception of the message the broker service will fetch a user from the queue and process the signal. When done, it will get a new user from the queue until the queue is empty. It will then sleep until it gets a new message. This way multiple instances of the same broker service act as workers to process the queue as fast as possible.