Trading Signals
Collection of the micro-services for the algorithmic trading
There are a lot of signal happening all the time, which could influence the trading pattern.
Usually, in past days trading solutions were built as a monolith application. Moreover,
there is a huge infrastructure for the processes automation: bash, python, perl, puppet, crontasks and so on.
Those infrastructure not only have the price, but also slow down the data circulation process.
That process could be explained as follows:
application
produce the data: logs, data from vendors, etc.
rotation
move the data to the storage
aggregation
takes the data and prepare aggregates
data analysis
takes the aggregates and data and produce the models
deploy
takes the models and reload the application
- goto step 1.
The whole cycle could be hours. But during the high-frequency trading it is necessary to get signal as soon as possible.
Actually some companies to build dedicated, physical network channel just because they want to react on the trading changes
faster than the others.
Of cause, for this particular project is not about such speeds, but if it is possible get some signals in a seconds and infrastructure cost
are close to, say 50$ per month, that is also not bad.
Data sources
Quick start
- Process
Installation
steps
- Process
Configuration
steps
run the docker-compose
docker-compose up -d
create signal
curl -v "http://localhost:8080/signals/trend" -X POST --data @.signal.trend.payload.resolved
check the logs
docker-compose logs
Installation
Clone the repository
git clone http://github.com/mshogin/trading
install docker and docker compose
please follow https://docs.docker.com/get-docker/
or run simple puppet manifest
sudo puppet apply deploy/profile.pp
To check docker-compose installation
$ docker-compose -v
docker-compose version 1.21.2, build a133471
Configuration
It comes with the default configuration of the application which is located in the configs
directory.
Currency pairs values vendor:
At the moment we support cryptocompare.com only.
You should obtain the api_key
please follow the next document: https://www.cryptocompare.com/coins/guides/how-to-use-our-api/
Once you got api_key
you need to
Google PubSub
(see https://cloud.google.com/pubsub/docs/overview)
Configuration steps:
- Create GCP service account and grand RW access to the topics
- Create topics in the GCP PubSub (see config/system.toml:Google:Topics)
Architecture
Messages flow
The basic workflow could be described as the following:
user, using REST API, creates a signal
he wants to receive.
Once signal is created and placed in the DB, the restapi
service sends a message to the signals
service to inform about new signal.
Then the signals
service do the following:
- sends the message to the
ticker
service to set up a new subscription
- subscribe to the
ticker.tick
messages and set a process-tick
callback
- once the next
ticker.tick
comes to the callback, the signal checks its conditions
- once conditions are met the requirements, the callback sends the following notifications
- to the
notification
service, to send the email notification to the user
- to the
ticker
service to remove the subscription
- to the
restapi
service to update signal status
- and remove
ticker.tick
subscription in the signals
service
Consider the ticker
service. Once it gets the message about new subscription it does the following:
- increment subscription counter (there could be several signals with the same asset)
- if it's the first time subscription,
ticker
requests a new subscription on vendor(cryptocompare for example)
The subscription counter is responsible for the life-time of subscription on the vendor.
That means that the ticker
unsubscribe from the vendor ticks only when the last signal is resolved.
Topics and events
There is a list of the topics:
- restapi
- signals
- ticker
- ticker.tick
- notification
Contribution
Please feel free to submit any pull requests.
Contributor List