go-trader: a financial exchange you can run against your own strategy

What go-trader is, and why it exists

go-trader is a financial exchange written in Go including a complete order book, the FIX protocol and market data distribution. The stated origin is worth repeating because it explains the shape of the code. It was originally developed to further the author's knowledge of Go and to test its suitability for high-performance financial applications, and it has continued to evolve into what the readme calls an ideal teaching and reference project for Go, covering interfaces, low-level networking, web development, JSON and goroutines. That is a different pitch from a trading platform product. The value proposition is that one repository shows several of Go's harder features applied to a domain where they genuinely matter, and where you can see the results in latency figures. There is a C++ version of the same project, cpp-trader, which the readme points at, with the note that it has fewer features.

The feature list, and what it means to implement

Client to server communication is available over FIX, using quickfixgo, and over gRPC, so a strategy can be written against either and the exchange does not care which. Market data distribution is UDP multicast, and there is TCP replay of dropped market data packets, which is the detail that makes the multicast approach usable in practice, since a dropped packet in a price feed is a silent hole in your data. Prices are handled with the fixed point library, which the author also wrote, so the binary representation of a price is exact rather than a floating point approximation. The supported order types are limit and market, and there is a REST API for accessing the book and the stats. On top of that sit multiple clients: a command line client, a server-side web interface built with Go templates, and a single page application web interface written with Lit. Two sample strategies ship with it, a market maker that masses quotes and a playback program that simulates markets from recorded market data.

Building it, and the commands to run

The install is a single go get.

go get github.com/robaho/go-trader

The build then compiles every command in the cmd directory into a bin directory.

cd go-trader
mkdir bin
go build -o bin ./cmd/...

And the run is three processes, each in its own terminal session.

cd go-trader

bin/exchange

bin/marketmaker -symbol IBM

bin/client

The readme adds one instruction that is easy to miss, and it is the kind of thing that costs an afternoon if you do not know it: ensure the correct interface is set in configs/got_settings for the client. The exchange, the market maker and the client all have to agree on which interface they are talking over, and the config directory at the top level of the repository is where that lives. If you want the Lit interface rather than the templated one, you also need to build its assets first, with npm run build in the web_lit directory.

The two web interfaces, and the REST API

There are two web interfaces and they are alternatives rather than layers. The default interface at the root path uses Go templates and server-side rendering, and the alternative at the path lit is written in TypeScript using the Lit framework and talks to the REST API. The REST API endpoints are listed plainly, one for the full book and one for the stats, both taking a symbol and both requiring a login with the guest credentials and the password. So the API is not a separate surface bolted on afterwards, it is the interface the Lit front end is built on and the one you would use to drive a strategy from a script. The repository has three screenshot images in its doc directory, one for the command line client, one for the templated web interface and one for the Lit interface, which is the quickest way to see how much of the exchange each front end shows.

The sample strategies, and what they are for

The exchange is designed to allow for easy back-testing of trading strategies, and the two samples are chosen to make that concrete. The market maker masses quotes against the market, and the playback program simulates a market from recorded market data, which is how you get a repeatable scenario rather than a random one. There is also a very simple sample algo, and the readme is honest about its quality. The program structure is applicable to many strategies that use an entry and an exit price, and it can be run in conjunction with the marketmaker sample to test the algo. The hint in the readme is worth keeping, because it describes the trap in every back-test that looks successful: the algo has a fifty-fifty chance of being successful except that the market maker bid and ask spread must be accounted for, which makes it far less than a fifty-fifty chance of being profitable. A strategy that ignores the spread it is trading against will look good and lose money.

The performance figures, and what they assume

The performance section is unusually specific about its conditions, and those conditions are the most useful part of it. The client machine is a Mac Mini M1 running macOS Sonoma, the server machine is a 4.0 GHz i7 iMac with 4 cores and 8 threads running macOS Monterey, and they are connected over 1 Gbit ethernet. A quote is a double-sided bid and ask, and the timings are measured from quote message generation on the client to the reception of the multicast market data on the client, so the number includes the network and the multicast distribution rather than just the handler. On that setup the headline is 90,000 or more quotes per second over the network using FIX with latency under 1 ms, and 400,000 or more quotes per second using gRPC with latency under 600 microseconds. The detailed numbers are given per benchmark run, with the FIX run at around 72,000 to 90,000 updates per second and average round trip times around 830 microseconds, and the gRPC run at around 410,000 updates per second with average round trip times around 605 microseconds. The readme also notes that the CPUs are saturated on both the client and server, which tells you these are saturation figures rather than idle ones.

The dependency list, and what it tells you

The go.mod file is a good map of the project, and it is short. The module requires Go 1.22. On the protocol side there is quickfixgo with its enum, field and fix44 subpackages plus the quickfix library itself, and google.golang.org/grpc at version 1.60.0 with the protobuf packages. On the data side there is the author's own fixed library, pinned to a specific commit, and shopspring/decimal for decimal arithmetic. For the terminal interface there is the author's gocui, along with termbox-go and go-runewidth underneath it. For the market data and utilities there is gohistogram for the histogram, gernest/hot, pkg/errors and golang.org/x/net. The point of the list is that the author wrote or maintains several of the pieces himself, which is the same reason the project reads as a Go teaching resource rather than an assembly of well-known libraries.

Where go-trader is the wrong tool

Three boundaries make it a poor fit for anything beyond its stated purpose. The first is the order model. Only limit and market orders are supported, so anything needing stop orders, iceberg orders, fills or cancels with quantities, or multi-leg instruments is out of scope, and the readme is direct about that. The second is the scale claim. The quoted throughput figures are the author's own measurements on one specific pair of machines with the CPUs saturated, which makes them a useful demonstration of what Go can do and a poor basis for capacity planning on different hardware. And the third is that this is a matching engine, not a venue. There is no counterparty credit risk handling, no settlement, no regulatory reporting and no connectivity to a real exchange, so the code answers questions about order matching and latency, and nothing about what it takes to actually trade.

Editorial conclusion

go-trader fits a developer who wants to test a trading strategy against a matching engine that behaves like one, with FIX and gRPC on the wire and market data over multicast, rather than against a mock that always fills. It also fits a Go developer who wants one readable codebase covering interfaces, low-level networking, web development, JSON and goroutines, since that was the stated purpose of the project. It does not fit someone who needs production features beyond limit and market orders, since those are the only supported order types. It also does not fit a user without a specific machine, because the benchmark numbers quoted are tied to a Mac Mini M1 client and a 4.0 GHz i7 iMac server on a 1 Gbit link, and they are the author's own figures rather than an independent measurement. Before you run it, build the Lit web assets with npm run build in the web_lit directory if you want the alternative interface, and set the client interface in configs/got_settings before starting the clients.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. robaho/go-trader on GitHub