Pooling vs. Web socket

You might have noticed that exchange functions on discrete ticks. One tick is the defined execution time frame of the exchange, and it's set to 1 second by default. So every one-second exchange takes all the new actions, checks the state of the order book, updates the order book (both bid and ask side), and checks if there are any new matches. If you'd like to explore this topic in-depth, please check the docs.

UI is the observer of the order book. To observe the order book properly, there are two approaches. API pooling and web socket listener.

The current implementation of Origin's UI reference implementation is using API pooling. One can argue that pooling creates unnecessary network traffic and is not an optimal solution. If you're on this side of the argument, you might want to consider implementing a web socket approach.

The truth of the matter is that we view the UI as a reference implementation and not of the product-ready level. Our team decided to take the easy road on this topic by taking into consideration available resources and added benefit. We're not expecting Origin to be a high-frequency exchange that needs to scrutinize every optimization opportunity.

That said, in the future, we might switch to a web socket approach. To stay in the loop about our architectural decisions, please follow our ADR.