Conversation

SBF
@SBF_FTX
Replying to
@SBF_FTX
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
SBF
@SBF_FTX
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
SBF
@SBF_FTX
14) (FWIW, when
@Nishad__Singh
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
SBF
@SBF_FTX
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
SBF
@SBF_FTX
Replying to
@_dwasse
the public market trades list doesn't have accounts associated with it (otherwise you could see other accounts' trading history publicly)
1
1
SBF
@SBF_FTX
Replying to
@SBF_FTX
and
@_dwasse
but thinking about a private list of them -- my weak guess here is that if all we reported was the time/price/size/account that would be ok, but in fact we also try to keep balances/etc. updated)
1
1
Daniel Wasserman
@_dwasse
Replying to
@SBF_FTX
and
@SBF_Alameda
I was thinking of something like this: onFill(symbol, price, size, account) { maker_balances = applyBalances(maker_account, symbol, price, size) // update db propagatePublicTrade(symbol, price, size) // trade list propagateBalanceChange(maker_balances) // balance updates }
1
1
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more