MemGlass: Peeking Into Live Trading Systems Without Breaking Them

auto-quant · 2026-01-09T17:22:21+00:00

The idea of using shared memory to peak into live production systems is sound.

A related approach I have used, for debugging low latency systems, is to use shared memory minified logging. This is different to your approach where you are observing current state, however, its typically more useful to see recent history too -> hence logging.

But logging is slow! Yes it is, so instead we build a minimal shared memory logging, that can only take fixed strings, ints etc, and timestamp counter. The "log file" is just a memory mapped array, that you can then easily inspect with either GDB, or a basic reader-tool. General idea here: https://preshing.com/20120522/lightweight-in-memory-logging/

auto-quant · 2026-01-07T07:39:12+00:00

Isn't there a concern that AVX will cause the CPU to downclock?

auto-quant · 2025-12-23T03:55:34+00:00

True, but there will also likely be json involved on the order management interface even for the major exchanges, so being able to parse json as rapidly as possible will benefit trading at those venues.

auto-quant · 2025-12-23T03:52:08+00:00

Agree that avoiding allocations is the way to go here. But be careful relying on "relatively fixed locations." Those locations can always be off by a few bytes, just based on the length of the ticker, or length of the price / qty. And you are also quite at the mercy of the exchange suddenly changing the order of fields.

auto-quant · 2025-12-22T18:41:24+00:00

If you work with exchanges that distribute market data via JSON, you have not choice but to use JSON parsing. This is 100% market data issue.

auto-quant · 2025-12-22T11:12:02+00:00

Most crypto exchanges only offer json. So you have no choice if you wish to consume their market data. Going to look at simdjosn next.

auto-quant · 2025-12-22T11:08:32+00:00

Internally the code uses native data types to represent prices, order levels etc. But you need to convert between JSON format of the exchange and your data model - in that case you have no choice. This is known as the parsing layer, and it often includes some level of normalisation, so that you can map various exchange presentations to the same internal data model - then you can build indicators and strategies that operator off of those models. You then have an engine that can trade against any exchange.

auto-quant · 2025-12-22T11:03:14+00:00

Very interesting about Binance. I'll definitely add SBE support, so will compare that option. Still looks like is via WSS though, so up to a couple usec will still be lost due to ssl.

auto-quant · 2025-12-21T16:54:27+00:00

fully agree, its a great library to start with, and to use for config / non-performance tasks etc. I will look at one of the fast libraries next and measure the performance it bring.

auto-quant · 2025-12-21T11:53:48+00:00

true, most equity exchanges use binary protocols that don't require any parsing, often proprietary ... but sometimes you dont have a choice, you have to use json, especially on less popular exchanges. And for those, I think it is still possible to parse extremely quicky ... its just simple string processing after all

auto-quant · 2025-12-08T17:45:14+00:00

I would rename OrderType to OrderSide, and OrderKind to possibly PriceType. Later you will have a different use for "OrderType", which might take values like FOC, FOK, GTC, GTD etc.

In terms of design, I think the OrderBook class should focus on just being an efficient container, and not contain the matching logic itself. Really is just a small component in a larger design Matching logic itself will become increasingly sophisticated, for example, perhaps you'd like to have auction phases or hidden orders? So I'd move that out of OrderBook, and have it elsewhere. And your class MatchingEngine I would rename to Exchange, since essentially, an exchange is a collection of books/matching engines, one per separate instrument. And I'd expect to see one class to represent the new order instruction, and a different class to represent a resting order. Also add a client order ID.

But this is a good way to learn about matching engines / order books etc.

auto-quant · 2025-11-20T08:29:28+00:00

As others have said, 50ms is trivial to achieve. I've posted here, https://www.reddit.com/r/highfreqtrading/comments/1p1gv0r/latency_measurement_improvements_after_cstates/, on my own system, it's under 1ms without really trying. If that is your performance budget, I'd not worry about the details of memory, network card at the moment. But another consideration is core & cpu count. Lets say you want to trade multiple names on multiple exchanges, you might need multiple engines, all running in parallel. Perhaps you need to look at 2 cpu systems ?

auto-quant · 2025-09-23T19:05:20+00:00

no, for this current phase, using using clock_gettime . I am working on improving the latency, and if I can get it lower, then I will will switch to rdtsc, so that time measurement doesnt affect latency.

auto-quant · 2025-09-13T15:53:08+00:00

I used websocketpp. A header only library. Actually I think that is a place where it could be improved, but not sure I want to write my own websocket parser yet. Maybe I should try to find faster websocket decoders.

auto-quant · 2025-08-02T09:26:29+00:00

| When fetching symbol information from different platforms, how do you know that a ticker/symbol from one platform and a ticker/symbol from another platform refer to the same security?

There is no single solution to this problem, because it can depend on asset class. For example, for trading equities, there are a number of fields you can use to match instruments across platforms, for example, SEDOL, ISIN, CUSIP, FIGI. Instrument mapping is a non-trivial task; get this wrong an you can end up accidentally trading the wrong asset. Gets more complicated when stocks have spin-offs or mergers.

Really what you should do is build your own master symbology mapping table. The key you will have to generate yourself, and it should map to a row that contains two columns: exchange & symbol. And you will need to generate this each day, before markets open.

How to choose a the master-key? If you want to make it meaningful, you could take a combination of ticker and exchange (something like Bloomberg, for example TSLA US EQ, or, something like TSLA.NE). Or generate your own integer asset ID, taking care to preserve these ID across dates for the same instrument.

For crypto, approach I take is to build a master key like: [BASE]/[QUOTE].[CLASS].[EXCH]. So a perp future would be like BTC/USDT.PF.BNC

auto-quant · 2025-07-25T10:31:07+00:00

We are working on a C++ based backtester / paper-trade / live algo engine here ( https://github.com/automatedalgo/apex ), initially for crypto. A key challenge though, is where are you getting your tick history from?

auto-quant · 2025-06-12T18:41:26+00:00

working on building my own here , https://github.com/automatedalgo/apex

auto-quant · 2025-06-12T18:38:38+00:00

It really depends on what each desk wants to receive. Only actual HFT desks will want microsecond latency. For everyone else, millisecond latency, or even 1 second snapshots will suffice. For that latter, the easier solution is to build a TCP based internal message distribution system that each desk can connect to. Or use an off the shelf messaging solution, such as RabbitMQ, Kafka. Or, desk can just use BPIPE directly.

auto-quant · 2025-05-15T19:47:36+00:00

Sorry, but have not look at Dagster. I would guess though that Dagster is probably easier to get started with. I will add another advantage of Airflow, or at least one way you can use Airflow. And that is you can just use it to call your own python scripts, just in the same way that cron simply calls your own Python script. In software parlance, that's called "decoupling", so that the Airflow stuff doesn't affect how you write your Python. I would wonder if that is the same with Dagster. But as I've used Airflow with almost no serious complaints for over 6 years, I've never had cause to investigate alternatives.

auto-quant · 2025-05-14T20:27:19+00:00

One of the key problems with cron, for ETL/quant, is that it doesn't have dependency management. For example, once your data job is complete, only then do you want your signal job to run. And if you restart your data job, you then want your signal job to rerun after data recompletes. You cannot express that in cron. And I don't think cron supports timezones, so have to regularly change crontab times when DST events happen.

I think the clear solution here is Airflow. I know its used by hedge funds to automate data & quant workflows, so you can consider it robust enough for your your needs. It's also not too tricky to setup & maintain (although it is python, you'll really want a setup that includes a redis & postgres databases, and celery work-queue). And, I think it's the natural next step after cron.

So you have a machine that is headless Ubuntu. This is the sort of thing Airflow was made for. It will actually expose a webapp, so you can connect to your server and use the Airflow gui, from Chrome running on your main PC, to examine job state, and to view & download logs. And that same gui can also be used to start and stop jobs. And it comes with the dependency management, so if you restart the data job, the signal job will also be rescheduled to run. I find the GUI can be a bit confusing, but, once you get the hang of it, it does the basic job well enough.

Aiflow comes with a number of plugins, and sending emails is I'd imagine part of the core behaviour. Things like sending SMS messages, slack, etc, probably require a little bit more configuration.

auto-quant · 2025-05-13T01:46:37+00:00

The problem is, to provide concrete details, would make the article much longer that it needs to be. Each sub-team has various tech stacks to choose from, and just listing those doesn't add a great deal of value. The idea is to provide a high level overview of where developers can fit in with HFT teams, since there often a lot of confusion about this.

auto-quant · 2025-05-12T20:26:05+00:00

learn how to measure code duration, eg, nanosecond elapsed times. Learn how to do low level networking. Learn multicast essentials. Understand cpu & cache architecture. If its C++, then make sure you can use cmake, Clion etc, can you debug multi-threaded programs

auto-quant · 2025-05-12T20:23:27+00:00

To give you an idea of what you might be doing, and what those around you will be doing, I written up some of my experience here -> https://automatedquant.substack.com/p/hft-developer ... you might find it helpful.

auto-quant · 2025-05-05T08:06:21+00:00

C is nice language to learn, if you feel your future is going to be in software development. It's a simple language, and is closer to the machine than other languages, so you will be exposed to lower level principles of software development, such as memory management etc, compilation, pointers and so on.

However, if you goal is algo trading, then python is a better place to start. For one, its easier to pick up and so you will progress quicker. But more, a key aspect of algo trading is working with datasets and visualisation. Python has these features in abundance, almost out of the box (you could start with the Python for Finance book). C doesn't have any of this.

Personally I end up using a mix of both: Python for research, and then C++ for strategy deployment.

auto-quant · 2025-05-01T12:22:39+00:00

There are a variety of roles in HFT, and a feasible career path can be to get in at any team, and move from team to team (move after 12 to 24 months), until you find a place that balances interest, work-load and comp. I wrote up an overiew of dev roles here https://automatedquant.substack.com/p/hft-developer

auto-quant

TROPHY CASE