Technical Challenges In Building Next Gen Real-Time Trading Tools

Looking back over the past year when we first started the project to build cloud based real-time trading tools, I have no idea it is that difficult. After all, real-time data vendors have been delivering such data for many years. I thought the technology must have matured to the point it would be easy to implement. I was totally wrong.

Time-Poll Has Its Limitations

Learned first hand that time-poll from your server is not a good idea.

When I first thinking of a real-time chat room, my team scrambled up a solution using simple WordPress commenting system together with some additional plug-ins and hacks. It was based on simple time-polling by the end users’ browsers. It worked beautifully for a very short while. As our chat room started to pack with more people, the weaknesses of this solution became obvious.

No matter how much CPU power we threw behind the web site, it kept breaking down from time to time. It is just way too much cost to redeliver the comments again and again. Each additional member joining the chat room to have a look at the discussions added more stress to the server. We had to restart the server several times a day or the web server would become inaccessible. It was a nightmare.

What our members did not know was that it also killed our first prototypes of various real-time trading tools. The real-time chat room was our test on server load considerations. It had proven to us that time-poll could not be the solution we are looking for.

A new solution had to be found.

Server-Side Push

Server-side push is the technology where the server can choose to push out data to the client with minimal cost to the server in terms of CPU load. What it means is that it is possible to broadcast a lot of information to many clients without overloading the server. It solves the problem with time-polling.

Think of server-side push as keeping a phone call connected all the time with your friend and shout to the phone whenever you want to say something. The other end, your friend, can hear you loud and clear. The nuisance of dialling again and again to establish the connection before delivering your message is removed.

The server-side push technology exists since the 1990s. The implementations of such technology were mainly vertical solutions for firms with special need. The technology company Akamai specializes in this and has been doing this for more than 15 years. The issue with solutions from Akamai and its peers is that they are very expensive for companies serving a small niche with limited number of clients. Companies like eSignal uses Akamai as its backbone for financial data delivery because of their efficiencies in moving large amount of data to many clients. You should understand though there is a premium to utilize such technology.

In 2013, the generic server-side push technology has matured. With several companies offering their services to companies of all sizes, some of them emerged as the market leaders. This offers me a chance to test drive my idea with controlled cost. If it works out, I can create a whole set of next generation real-time trading tools. It is something so exciting I have to give it a try.

One Year Of Testing, One Winner

My team created connections to several server-side push services. We plugged every one of them into our real-time chat room and stress tested them with our sandbox. We have collected statistics on their perform during busy trading days to see if they function properly.

Nine months into our test we did not find a winner.

The last one on my list of services to try out was Pubnub. And it worked out!

Pubnub works so well with our testing that we simply jump the gun to build around it the real-time price levels tool. It is a beauty to see what can be done when the backend provided by Pubnub doing the heavy lifting. We no longer need to worry about the server load issues and can concentrate on functionality and design of the real-time trading tools.

Funny thing with the experiment is that we randomly picked from these real-time delivery services to conduct our tests yet it is the last one out of the four firms we tried out that fits our need. One way to see this is that our time being wasted (almost a year!) and bad luck for us. The other way to see this is that we have learned a lot on the way in connecting our server applications to the internet services.

The Twitter Experiment

During our quest for means to implement real-time trading analytics, we’ve tested Twitter as a means to carry our real-time analytics. We did it out of curiosity – would Twitter, a free service, let us piggy back on its superior infrastructure?

I have documented the experiment back in November. It gave us a different perspective into the issues related to real-time data delivery. Namely, it is still costly to deliver information real-time. Otherwise why would Twitter imposes such limitation on their service?

Going Forward

After one long year, we have managed to solve the real-time analytics delivery issues. In terms of Internet development cycle, that is an eternity. I have been taking it slow for good reasons though.

The obvious one is that trading is still occupying majority of my time I set aside for work.

The other one is that we did not really have the experience in building web applications one year ago. Now we have gained the experience.

The last reason is that we need to develop a set of programming libraries to make the development cycle down the road more manageable. This goal is mostly accomplished as we delivered the latest update to the beta release of the Real-Time Price Levels Tool.

I guess I have run out of excuses to delay our projects any further.

Time to get things done.

Share