Conversation

Replying to
10) At least, not if they're in the same market. So you can't have one computer handle Alice's matching and another handle Bob's, at least not trivially, or they'll clash with each other, both thinking they lifted the same offer. This is when it gets tricky to increase capacity
1
3
11) e & f are somewhere in between. In some sense, f should be parallelizable: just have separate computers handle updates for each fill. But what if Bob simultaneously buys BTC/USD and BTC/USDT. Both increase his BTC balance.
1
3
12) If they don't talk to each other, both will report too low of a BTC balance for him! So there's still some tricky work to do there on the interplay between similar but different fills. And if you can't parallelize it, then you're stuck going one at a time.
1
3
13) And if you're going one by one and trading is really busy, the _single_ computer handling all fills notifications will get a bigger and bigger queue of things to notify. So at some point the real solution here has to be finding a way to do more than one at once.
1
7
14) (FWIW, when and Gary were talking about this today, the metaphor used was basically of a symphony with a conductor, and improvements were to the conductor that coordinated which computer processed which fills.)
2
14
16) One missing thing from this: some of the 'clashing' when you try to parallelize things comes from updating the same single database too frequently; there's a data storage parallelization problem that mirrors the data processing one.
3
13
This Tweet is from a suspended account. Learn more
Replying to
in fact I basically am not, unless you count shitty VBA code :P but I spend enough time project managing devs that I try to pick up on what's going on
1
2
Replying to and
Great management and team...ftx have had an amazing year in volume and innovative solutions. Can't imagine the future, u guys really helping the industry integration.
1
1