QuickFIX - Receive and send orders from different algorithms (sources)

Question

I built a FIX Initiator Application using the QuickFIX/J library to send orders to my broker. If you don't know what is a FIX Application, consider that my program is an application that sends message to a server through TCP connection.

To get and send the orders created by multiple algorithms I have a Directory Watcher (WatchService) that watches for modifications on a local directory that is synchronized with a S3 bucket using AWS Cli.

This approach works well, except for the fact that I have to wait about 6-8 seconds before the file is on my local directory, so I can parse it to fix orders and send to broker's FIX app. I really would like to decrease this delay between the order creation and the moment when it is send to the broker.

What are the possible solutions that I'd tought:

1) Reading directly from S3 bucket without using AWS CLI

2) Opening different FIX sessions for each different algorithm

3) Instead of reading from a bucket, peaking a database (MySQL) for new orders. The algos would generate table rows instead of files

4) Having an API between my FIX application and the algorithms, so the algos can connect directly with my application.

Solution (1) didn't improved the order receiving time because it takes about the same time to list S3 objects, get summary and filter the desired file.

Solution (2) I didn't tried, but I think it is not the best one. If I have, for example, 100 different strategies I would have to open 100 different connections and I am not sure if my broker app can handle. But I may be wrong.

Solution (3) I also didn't tried.

Solution (4) is what I believe that is ideal, but I don't know how to implement. I tried to create an REST API, but I don't know if it is conceptually correct. Supposing that my FIX application is currently connected to the broker's server, my idea was to (i) create a new webapp to create a REST API (ii) receive order info through a API, (iii) find the current alive session and (iv) send order to broker server using the current session. Unfortunately, I was not able to find the current session by ID using the following on a different of the class that is running the FIX application:

SessionID sessionID = new SessionID("FIX.4.4", "CLIENT1", "FixServer");
    Session session = Session.lookupSession(sessionID);

What I would like to hear from you:

• What do you think that is the best solution to send FIX orders created by multiple sources?

  • If I want to create an API to connect 2 different applications, what are the steps that I can follow?

I am sorry if I was a bit confuse. Let me know if you need further clarification.

Thank you

Answer 1

Q : What do you think that is the best solution to send FIX orders created by multiple sources?

Definitely the 4) -ie- consolidate your multiple sources of decisions and interface the Broker-side FIX Protocol Gateway from a single point.

Reasons:
- isolation of concerns in design/implementation/operations
- single point of authentication/latency-motivated colocation for FIX Protocol channel
- minimised costs of FIX Protocol Gateway acceptance-testing (without this Tier-1 market participants will not let you run business with, so expenses on FIX Protocol E2E-mutual-cooperation compliance-testing do matter - both costs-wise and time-wise )

Q : what are the steps that I can follow?

Follow you own use-case, that defines all the MVP-features that need to be ready for going into testing.

Do not try to generalise your needs into any "new-Next-Gen-API", your trading is all about latency+trading, so rather specialise on the MVP-definition and do not design/implement anything beyond an MVP with minimum latency (overhead) on a point to point basis. Using stable professional frameworks, like nanomsg or ZeroMQ , may avoid spending a bit of time on reinventing any already invented wheels for low-latency trading messaging/signaling tools. Using REST is rather an anti-pattern in the 3rd millenium low-latency motivated high performance distributed computing eco-system for trading.