gotrade

README

GoTrade

GoTrade is a FIX protocol electronic trading and order management system written in Golang, structured for typical multi-asset instituional use

Status

This project is currently more of a proof of concept. It is no where near in completeness of a commerical product. This public repo serves as mostly for the purpose of experimenting and share of ideas.

Getting Started

$ go get -u github.com/cyanly/gotrade

Features

• Trade in real-time via FIX through the broker-neutral API.
• Normalized FIX order flow behavior across multiple FIX versions and asset classes.
• Pure Go.
  • Platform neutral: write once, build for any operating systems and arch (Linux/Windows/OSX etc).
  • Native code performance.
  • Ease of deployment.
  • Lack of OOP verbosity, works for small and big teams.
• Protobuf.
  • Binary encoding format, efficient yet extensible.
  • Easy Language Interoperability (C++, Python, Java, C#, Javascript, etc).
  • Protocol backward compatibility.

Design

└─ gotrade/
   ├─ core/                 -> The low-level API that gives consumers all the knobs they need
   │  ├─ order/
   │  │  └─ execution/
   │  ├─ service/
   └─ proto/...             -> Protobuf messaging protocol of various entities
   └─ services/             -> Core services managing multi-asset order flow
   │  ├─ orderrouter/       -> Centralized management facility for multi-asset global order flow
   │  ├─ marketconnectors/  -> Managing FIX connection to each trading venue, also performs pre-trade risk checks
   │
   └─cmd/...                -> Command-line executables, binary build targets
   

Examples

The best way to see goTrade in action is to take a look at tests (see Benchmark section below):

Pre-Requisites:

• Go 1.4 or higher
• get dependencies:

$ cd $GOPATH/src/github.com/cyanly/gotrade
$ go get -u -t ./...

OrderRouter and MarketConnector test cases will mock a testdb and messaging bus for end-to-end, message to message test.

$ cd $GOPATH/src/github.com/cyanly/gotrade/services/orderrouter
$ go test -v 

$ cd $GOPATH/src/github.com/cyanly/gotrade/services/marketconnectors/simulator
$ go test -v 

Benchmark

Machine: Intel Core i5 CPU @ 2.80GHz + Ubuntu 14.04 Desktop x86_64

• test/benchmark/client2fix_test.go
• CL ⇒ OR:
  Client send order protobuf to OrderRouter(OR)
• OR ⇒ MC:
  OrderRouter process order and dispatch persisted order entity to target MarketConnector
• MC ⇒ FIX:
  MarketConnector translate into NewOrderSingle FIX message based on the session with its counterparty
• FIX ⇒ MC:
  MarketConnector received FIX message on its order, here Simulator sending a fully FILL execution
• EXE ⇒ CL:
  MarketConnector publish processed and persisted Execution onto messaging bus, here our Client will listen to

Included:

• from order to FIX to a fully fill execution message to execution protobuf published back
• serialsing/deserialsing mock order into protobuf messages
• Request/Publish and Response/Subscribe via NATS.io message bus
• Time spent in the Linux TCP/IP stack
• Decode FIX messages and reply by a simulated broker

Excluded:

• Database transaction time (hard-wired to an inline mock DB driver)

Result:

• 0.176ms per op, 5670 order+fill pairs per sec

Limitations

Contributing

GoTrade © 2016+, Chao Yan. Released under the GNU General Public License.
Authored and maintained by Chao Yan with help from contributors (list).
Contributions are welcome.

cyan.ly  ·  GitHub @cyanly  · 

Documentation

Overview

GoTrade is a FIX protocol electronic trading and order management system written in Golang, structured for typical multi-asset institutional use.

Dependencies:

gogo/protobuf
  A fork of golang/protobuf with tweaks and extras
quickfixgo/quickfix
  FIX Engine in Golang
nats-io/nats
  Performant messaging bus in Golang, seems resemblance of TibRV

There are sub-packages within the gotrade package for various components:

core/...:
  The low-level API that gives consumers all the knobs they need
proto/...:
  The messaging protocol of various entities, in Protobuf format.
services/...:
  Core services managing multi-asset order flow
database/...: (not provided yet)
  SQL scripts and data layer APIs (PostgreSQL here but the idea is to
  support different storage engines without breaking everything)

Then on top of the core packages, we have:

cmd/...:
  Command-line executables, a.k.a final products
test/...:
  Integration tests, etc.

To avoid cyclic imports, imports should never pull in higher-level APIs into a lower-level package. For example, you could import all of core and shell from cmd/... or test/..., but you couldn't import any of shell from core/....