Live data from Hacker News

Production engineering when trading billions of dollars a day [video]

youtube.com

21–30 of 54 posts

Re: Production engineering when trading billions of dollars a day [video]

#21
I love talks like this so much. Trading isn't something I hardly ever think about as I live/work in a bubble of sorts, and it was a fascinating listen.

I have heard similar talks from Shopify and such back in the day, about their own product, but always love listening to more.

Re: Production engineering when trading billions of dollars a day [video]

#23

I'll never understand how these cognitive elites live. They're just a completely different kind of human than the rest of us.

What do you mean by “cognitive elites?”

I’ve met some exceptional people: top researchers from top universities from several fields, super well paid engineers working on products you probably use, some of the best hackers an advanced persistent threat actor could ask for; they’re just people.

I think if you get a collection of competent, thoughtful people together they would come up with similar solutions to the problems discussed in this talk.

Re: Production engineering when trading billions of dollars a day [video]

#25
post #2

This is a good talk. Really gets into the details of how things differ from the classical SaaS or consumer product. I've been doing reliability for most of my career, and have always been able to hide behind, "We're not a bank, if we lose a few requests it doesn't matter". They can't do that. :) One advantage that they have is that the market closes, so they can do maintenance that takes the whole system down, but wh…

there’s a move now towards 24/7 trading. I guess we’ll see how the rigors of the trading environment mesh with zero down time. I’m sure the rollout will be slow and steady.

Only US. Other markets barely have liquidity during daytime and get most liquidity in opening and closing auctions. Maintenance periods are actually a complication. A few more state transitions for the system, but barely used for maintenance. The only value is for upgrades, which would still be scheduled with the market down and systems up, as participants also need to transition codebases for breaking changes, a test weekend or more is required etc. These systems are extremely resilient. You most often get an incident not because the system is down but because the latency profile has changed by a few ms.

Re: Production engineering when trading billions of dollars a day [video]

#26
post #4

Earlier quoted context omitted.

I've seen that. I suspect the exchanges will never go for it for this exact reason -- they need downtime for maintenance. But if does go through, it will be a fun challenge to get 100% uptime! I've always said that with infinite money we could get 100% uptime, but no one has infinite money. Trading firms are about as close as I can imagine to infinite money though.

How do you think on-chain exchanges do it? Hyperliquid has 16 employees, not engineers...total employees. It is possible, it isn't going to be possible for many of the legacy exchanges. I work with a major one and, being honest, from day one it was obvious they were incompetent. They employ a huge number of engineers and are unable to deliver basic features at any reasonable pace. Not even remotely close to it either…

The first 90% of features takes 10% of the time to deliver. You are comparing capital infrastructure markets with deep regulatory obligations and multiple stateful interfaces (OUCh/FIX) to retail focused matching engines with a very slim stateless protocol surface (REST).

Re: Production engineering when trading billions of dollars a day [video]

#27

Earlier quoted context omitted.

Fastest ones are processing a block every 10ms. It depends what you mean by easy. Even if you are using a slow chain, you still have to compete for finite block space, you still have to work out how to risk/matching fast, etc. With chains built for exchange use, operating them easier, that is why they don't require thousands of engineers. But the actual technical capability of the system is significantly in excess of…

The EOD reconciliation (and corresponding inability to settle a position in milliseconds) is a feature - it allows "obvious erroneous trade" roll-back mechanisms, etc. Very few people want the financial system to be a contractual suicide pact - they want it to be predictable, but when the unpredictable happens - they want the retail and institutional investor to be protected (the HFT players can go beat each other up…

> they want the retail and institutional investor to be protected

That costs money, indirectly

Re: Production engineering when trading billions of dollars a day [video]

#28
post #4

Earlier quoted context omitted.

I've seen that. I suspect the exchanges will never go for it for this exact reason -- they need downtime for maintenance. But if does go through, it will be a fun challenge to get 100% uptime! I've always said that with infinite money we could get 100% uptime, but no one has infinite money. Trading firms are about as close as I can imagine to infinite money though.

I hated my time as an SRE. But … can’t it be done with some combination of canaries and blue green deployments and extensive testing? Where when things look good you just swap all the traffic to the good stuff keeping the rollback hot etc etc?

There are different kinds of updates that influence options and feasibility. Keeping in mind that deep in the heart of an exchange is a single threaded process, the sequencer. Therefore, you have three layers, external facing protocols, sequencer/matching engines, and internal interfaces. Internal interfaces are the easiest for b/g. External protocols, any change worth its weight changes the protocol and therefore requires participants to change their codebases too. Versioning protocols is an option, but still the integration with consumers is much more transparent and usually you have them test on pre-prod environments, occasionally also requiring attestation and conformance testing (regulated markets). Sequencer and matching engine are at the core. You could do parallel runs but not b/g. Theoretically you could abstract the matching engine and keep a barebones sequencer immutable, but this will have performance implications. So yes, you can do things, but not in a completely transparent way, unless if you introduce an “upgrade jitter” to give you a window for transparent upgrades. It’s an interesting domain, I think people will just accept occasional downtimes as a better option than constant jitter cost.

Re: Production engineering when trading billions of dollars a day [video]

#29
post #21

I love talks like this so much. Trading isn't something I hardly ever think about as I live/work in a bubble of sorts, and it was a fascinating listen. I have heard similar talks from Shopify and such back in the day, about their own product, but always love listening to more.

Which Shopify talks?

Re: Production engineering when trading billions of dollars a day [video]

#30
post #24

Standard SRE operations. Didn’t find anything notable. The clickbait title of "billions of dollars a day" is nothing to praise.

LOL, no. That's bisecting the patches to find the spurious latency jitter in the critical path, that's, carefully planning apps to fit the specific NUMA design, being on the first name basis from the engineering of NIC vendor, etc, etc.

It's fun, because one lost or late packet is an issue immediately red in the monitoring.

I've been SRE too and the most it brought to the table is a concept of error budget.

I can only agree that "billions of dollars" in trades is not much.

Post reply on HN