Opinion: auto-scaling is not really good with burst that need to be handled in matters of milliseconds.
Show this thread
TIPS: 1. use bare-metal servers 2. ensure your infra/services can handle 10x spikes in milliseconds, not minutes 3. UI should rely entirely on websockets 4. push users towards websockets 5. use standard DBs only for historical data, serve real-time data via in-mem processes
-
-
BONUS: 6. listening to
@Metallica while coding improves both quality and speed
Show this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
seems obvious... cc
@coinbaseThanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Or properly implement caching? and structure / config your DB? Use GRPC instead of plaintext websockets? That said Bitfinex is functionally more complete than others and way more responsive ^^
-
gRPC is cool, but I kind of prefer working directly on ZeroMQ. It's really powerful and removes central brokers. Kind of helps keeping latency down. We're experimenting really hard with reliable multicast too.
- Show replies
New conversation -
-
-
What about data races, what do you use to avoid them?
-
Data is sequenced by the matching engine
- Show replies
New conversation -
-
-
Re: websockets Men...better binary over server side streams http/2 if starting now in 2020
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Opinion : code plain old desktop UI with raw sockets (or zmq) instead of web/js and websockets. Speed is at least 20x.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
Time to write a book Paolo..
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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.