1/7 Problem: How to scale trading/liquidation engines up to 500k/1M/10M users? 100k users are manageable, but eventually single threaded architecture will bottleneck growing number of users.https://twitter.com/paoloardoino/status/1238965074427088903 …
-
Show this thread
-
2/7 * The order book (OB) for each pair is run on a single thread, with its own I/O queues. * User data UD is deterministically sharded among different threads * Liquidation engine (LE) is a set of threads with direct mem access to user data threads (positions, balances, ..)
1 reply 0 retweets 6 likesShow this thread -
3/7 * LE interacts with OB via in-mem priority queue. * LE adds to a liquidation-order (LEO) enough meta-info for the order book thread to evaluate if liquidation should still happen, bankruptcy price, ...
1 reply 0 retweets 4 likesShow this thread -
4/7 * Each LE sorts users by risk (probability of getting liquidated). * Improvement: a single shared sorted map can be generated across the threads
5 replies 0 retweets 5 likesShow this thread -
Replying to @paoloardoino
so a hack to get faster order processing is to have a high chance of being liquidated
1 reply 0 retweets 0 likes -
Replying to @marketcapone
Why? Not sure from where you deducted that. Users get liquidated only when they should. The system is just more scalable.
1 reply 0 retweets 0 likes -
Replying to @paoloardoino
"Each LE sorts users by risk (probability of getting liquidated)." I interpreted 'sorts' to mean 'decides which orders to process first' - if that's accurate then one could ensure their orders are processed fast by engineering a high probability of being liquidated.
1 reply 0 retweets 0 likes
LE and normal order insertion use 2 different queues. LE has a priority queue, to not use the same one of general order insertion.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.