Комментарии:
Really loved the content
ОтветитьCool resuming now!!
ОтветитьThanks 🌹
ОтветитьGreat content, keep it up!!
Ответитьwould be cool if next video was about exchanges
ОтветитьKeep up the good work Jordan!
ОтветитьThank you for the great content.. Helps us a lot
ОтветитьGood stuff! Would appreciate timestamps.
Also, I feel the justification for mysql could be bolstered by some read and write throughput assumptions tying back to 100M DAUs. e.g. 100M DAUs with limit of 100 orders per day would mean a max of 12k writes per second for a 24hr trading assuming zero spikes.
Additionally, for data oriented engineers, we could talk about the homepage dashboard service where a read heavy & real time analytics database might be a good choice for showing historical performance of the user portfolio and other stats.
exactly what we asked for ;)
ОтветитьQuick question: in the final diagram you drew the websocket connection as not passing through the pricing service load balancer between the client and the user server. Was that intentional and does it imply websocket connections usually don't work with load balancers?
ОтветитьGreat content, thanks! I have been going through your database videos and they have been really helpful. Could you please do a design video on Multi-engine malware analyser?
ОтветитьCan we use a message queue in between publisher and pricing server ? This will decouple both services and publisher will not be blocked on the response from pricing server.
ОтветитьDope video oh great one! I have a question about the exchange order flow. If I buy a stock and the server makes an order with the exchange, is there some sort of callback from the exchange when it’s filled?? How does Robinhood know when an order is filled or not? Thanks very much
ОтветитьWhere is your finance knowledge coming from?
ОтветитьIsn't it ideal to use a queue(Kafka) between the Publisher servers and the Pricing servers? or is that the intention and not specifically mentioned in the final design diagram? thank you!
ОтветитьFor pricing server/service, I am still not convinced about the need for Websockets. The user is unlikely to subscribe/unsubscribe to stocks as frequently as they would care about getting the current price of stocks. So bidirectional communication aspect of Websocket is not really useful? For near real time updates, I am wondering if we could get away with SSE considering the cost of maintaining web socket connections and a second/two of extra delay in getting updated prices will have negligible impact on how the client decides to act on it. Thoughts?
ОтветитьGreat video Jordan! I was wondering though would it make sense to have a distributed cache Redis style as opposed to intermediary cache replicas on the read path which can enable construction of portfolios for users? The key thing here seems to be minimization of latency and with Redis Enterprise one could scale ops/sec quite effectively for building of ticker trackers for end users.
Second as an optimization - the websocket could selectively send a message to the read path that the stock tracker / pricing page is up so now send me informaiton about quotes to reduce the load on pricing servers.
Finally would Vitess make sense here for horizontal sharding of the MySQL tier? This way the application does not have to implement much around horizontal sharding itself.
Awesome video nonetheless ty! I tried the same problem ahead of time myself - and roughly arrived at a similar solution!
LMAO for tech lead part
ОтветитьLot of sharding there, need to clear my concept on this first 👍
Ответитьthanks for the video;
instead of using websocket for client <-> user_server and user_server <-> pricing_server, what about using server-sent event? so we have automatically reconnection
What tool do you use for the note?
ОтветитьI feel like you can use windowing with flink to consume data from exchange because that will buffer it before hitting the pricing server so we reduce the load on the pricing server.
Edit: It seems that the pricing server isn't doing anything complex, but I feel that it would require more logic to upkeep then just throwing in flink
Did I miss the PositionsDB route explanation ? OrderDB -> CDC Kafka -> Sream Consumer -> PositionsDB?
Ответитьfor hot assets like AAPL, GOOG, do they have dedicated pricing servers? for example, one layer-1 AAPL pricing server directly connect to publisher, multiple layer-2 AAPL pricing server connected to the layer-1 AAPL pricing server, user server will connect any one of the layer-2 pricing server
Ответить