This page describes the various parts of the Liminal Capital trading system.
Microservices are applications that run continuously or on-demand to accomplish a part of the work of the Liminal Capital trading system.
Currently microservices can run in three places
in the us-east-1 AWS region (N Virginia)
Although two clusters exist, they are not fully configured and are not being used. They are a Windows server cluster and a Linux cluster. The Windows cluster will be used to run C# microservices. The Linux cluster could also be used to run C# microservices but, for now, is intended to be used for those microservices unfortunate enough to be written in Python.
There are two services that run in an EC2 machine: the two public-facing sites, research.liminal-capital.com and clients.liminal-capital.com. These have public IP addresses so that they can be visible on the public internet and are hosted on IIS (Internet Information Server, the Microsoft web server).
Currently all of the microservices, except for the public-facing sites, run on office workstations. There are two reasons for this. There are a number of UI Windows applications that are run by a user that needs to see information about the various parts of the system.
Secondly there are microservices that depend on a licensed workstation application which have a machine-locked license. The first group of these use the Bloomberg API and must run on the same machine which runs the Bloomberg application that provides that API. The second group are applications that use the Interactive Brokers API. These do not need to run on the machine that provide the TWS (Trader Workstation) API but must access the API via a connection to a specific office machine
Every microservice is assigned a four digit code. This code is a succinct identifier for the each microservice that is used to refer to it in various UI applications, in error messages, and in logs. These codes are statically assigned to a microservice when it is built.
Although in today's system each microservice runs as a single instance. There is no reason that we cannot run more than one instance of a microservice as long as the microservice is designed to allow this.
Microservices run as parts of a system where there is frequent communication among them. We currently use Redis pub/sub for this communication using JSON payloads. Pub/sub involves one or more subscribers to each kind of communication (called a channel) where each publisher creates messages on the channel and all subscribers to a channel receive all messages published on it. This scheme works well all relevant microservices are running but if a subscriber fails it will not receive any messages published from that time until another instance of the subscriber is created.
This is different from a message queue where messages published to the queue remain in the queue until a subscriber retrieves it. The disadvantage of this is that if there are more than one subscriber each mesasge is generally recieved by only one of them. Some queues have more complex mechanisms to address this issue. At this time, we are looking into replacing Redis with a message queue or a similar service but have not implemented such a mechanism.