Live data from Hacker News

How exchanges turn order books into distributed logs

quant.engineering

61–70 of 73 posts

Re: How exchanges turn order books into distributed logs

#61
post #42

Earlier quoted context omitted.

Also three uses of a semi-colon for no reason. Nobody writes like this. > The log is the truth; the order book is just a real-time projection of this sequence. > The book is fast; the log is truth. > Matching engines can crash; the log cannot.

I need to sharpen my BS sensor. At first glance, I struggled to parse the voice in the article. Going back to the article I can now see the obvious gaps. Generally, AI tends to say things that make us go - "what the hell is this" ? for example in the article "The Problem: Ordering Chaos" is a very weird way to phrase it. As a human I struggled to accept it, and I did by stretching the meaning of that phrase to world…

I didn’t catch it either on the first pass but also felt something was off about the article, as if a human had sanitised most of the AI idiosyncrasies out.

Now I have taken note to auto-distrust any “article” that lacks an author name, who is willing to personally own any accusations of the article being AI slop.

Re: How exchanges turn order books into distributed logs

#62

Earlier quoted context omitted.

Off the cuff, id expect this leads to less improvement than you might think. The vast majority of orders, especially orders arriving in sequence close to one another, are likely on a small set of extremely liquid symbols, and usually all for prices at or near the top of the book for those symbols. Happy to discuss more, might be off the mark... these optimizations are always very interesting in their theoretical vs a…

in high scale stateless app services this approach is typically used to lower tail latency. two identical service instances will be sent the same request and whichever one returns faster “wins” which protects you from a bad instance or even one which happens to be heavily loaded.

And the tail latencies are wildly improved with each addition dup. Has to be idempotent of course.

Re: How exchanges turn order books into distributed logs

#63
post #37

Earlier quoted context omitted.

B/c, by design, you want the archived stream of events to include everything. e.g. a lot of these systems have a "replay" node that can be used by components that just restarted. You want the replay to include ALL of the messages seen so you can rebuild the state at any given point. (There are, of course, tradeoffs to this so I'm just commenting on the "single sequencer" design philosophy)

by definition: an exchange doesn't need any reference to outside market data even for systems built on a sequencer which do (e.g. an OMS), the volume is too large the usual strategy is for processes which require it, is to sample it and them stamp it on commands which maintains the invariants (my background: I have been a developer on one of Mike Blum's original sequencers)

How would an exchange enforce the trade through rule without any outside market data?

Re: How exchanges turn order books into distributed logs

#64
post #18
post #2

This article both undersells and oversells the technical challenge exchanges solve. First, it is of course possible to apply horizontal scaling through sharding. My order on Tesla doesn't affect your order on Apple, so it's possible to run each product on its own matching engine, its own set of gateways, etc. Most exchanges don't go this far: they might have one cluster for stocks starting A-E, etc. So they don't eve…

> My order on Tesla doesn't affect your order on Apple not necessarily many exchanges allow orders into one instrument to match on another (very, very common on derivatives exchanges)

Yes, I was going to note that this doesn't necessarily apply on derivatives exchanges. But

a) I don't know of any exchange where this could be true for specifically Apple and Tesla, so the example is OK

b) you can still get some level of isolation, even on commodities exchanges you can't typically affect the gold book with your crude oil order (the typical case is that your order to buy oil futures in 2027 matches against someone selling oil in 2026, plus someone selling a calendar spread)

c) for exchanges that do offer this kind of functionality, one of the ways they deal with high volumes is by temporarily disabling this feature.

Re: How exchanges turn order books into distributed logs

#65

Earlier quoted context omitted.

Off the cuff, id expect this leads to less improvement than you might think. The vast majority of orders, especially orders arriving in sequence close to one another, are likely on a small set of extremely liquid symbols, and usually all for prices at or near the top of the book for those symbols. Happy to discuss more, might be off the mark... these optimizations are always very interesting in their theoretical vs a…

in high scale stateless app services this approach is typically used to lower tail latency. two identical service instances will be sent the same request and whichever one returns faster “wins” which protects you from a bad instance or even one which happens to be heavily loaded.

I'm not sure I follow. In this instance we're talking about multiple backend matching engines... Correct? By definition they must be kept in sync, or at least have total omnipotent knowledge about the state of all other backend book states.

Re: How exchanges turn order books into distributed logs

#66

Earlier quoted context omitted.

I've been wondering if the stock market would be more efficient if trades executed only every instead of continuously, i.e. every 1 second an opening trade style cross book clearance happens. Orders would have to be on the book for a full interval to execute to prevent last millisecond rushes at the end of an interval I'm probably missing some second order effects but it feels like this would mitigate the need for ra…

You could do this but the cost would be wider bid/ask spreads for all market participants. If you make it harder for market makers to hedge their position, they will collect a larger spread to account for that. A whole lot of liquidity can disappear in a second when news hits. I’d rather have penny-wide spreads on SPY than restrict trading speed for HFTs. Providing liquidity is beneficial to everyone, even if insane…

Would be interested to see real numbers around societal value from marginal added liquidity versus aggregate spend into the zero sum arms race.

I have also seen enough to be quite sure that many hft strategies are quite normie investor predatory.

Again, I’m not zealot. I trade stuff. I love liquidity. I’m happy to pay someone some fraction of a penny to change my mind. Service provided. But the returns from vanilla liquidity provision commoditized long ago to uninteresting margins. That leaves a lot more of the hft alpha pool in the predatory strategies and capital flows where the incentives are.

Re: How exchanges turn order books into distributed logs

#67
This distributed logs nature of the exchanges is very much suitable for Kafka.

But for the required stringent latency, Kafka for head of line (HoL) blocking under concurrent events can be an issue though [1].

[1] What If We Could Rebuild Kafka from Scratch? (220 comments)

https://news.ycombinator.com/item?id=43790420

Re: How exchanges turn order books into distributed logs

#68

Earlier quoted context omitted.

You know how coders are expected to grind out leetcode interviews? For the finance fields, a common interview topic is what you read in “The Journal” (WSJ). So just stay on top of it for a few weeks, see some trends, etc.

I’ve worked in finance for 25 years and never even heard of this coming up in an interview.

Imo it's not out of place in context if one is trying to determine if the candidate has an interest in finance.

Now, I'm not disqualifying them if they dont read the journal. But if they can't demonstrate any proactive interest in finance, or tell me about some happenings/events/stories they personally find interesting (theres a ton of interesting stuff happening) its definitely an amber flag.

Re: How exchanges turn order books into distributed logs

#69

How long can the exchanges scale their sequencer systems (which are sequential) vertically? The trading volume is only rising with time at a higher rate than the advancement of low latency tech.

In the most ideal case a sequencer can handle ~half a billion orders per second if all it's doing is assigning a number to each item. LMAX Disruptor using value types pushes 4-500 million events/s on modern hardware.
Post reply on HN