Prediction Market System Architecture

Recently I was working with a prediction market system. In a prediction market, the goal is to predict something such as the winner of a political election with three candidates. You get a group of experts who buy and sell shares of the candidates in a way that’s similar to how the stock market works. The number of outstanding shares of a candidate can be mathematically mapped to the probability that the candidate will win.

The system I was working with was a research project written in Java. The architecture of the system was something of a Frankenstein because the intention was to explore complex variations of prediction markets, and the system evolved over the course of several years.

The prediction market system had about 15,000 lines of code. Originally, input came from the keyboard, processing was performed by an in-memory Java object called the engine, output went to the screen. State persistence — the number of shares of each candidate held by each expert — was held in memory but could be written to and read from text files.

The research-focused system was adapted to a prototype that allowed real users. A SQL database storage sub-system was added, client communication via sockets was added, and a Web user interface was added. At this point the system became very difficult to manage and modify.

Now, suppose you want to architect a prediction market system from scratch. There are many possible designs. Perhaps the best approach would be to use a traditional three tier architecture where you have a backend SQL database that holds user data and “game” (one prediction effort) data, and a Web page front end.


The middle tier would do the logic which involves 1.) calculating the current costs of shares of each game option, 2.) calculating the current probabilities of winning for each game option, 3.) a handful of miscellaneous calculations such as cost initialization.

Because prediction market calculations are relatively lightweight, they could be performed a.) on the client (which would be JavaScript code), or b.) on the Web server (which would be C# code, assuming a Microsoft technologies environment), or c.) on the SQL Server (with T-SQL in the form of a stored procedure).

A variation of design b.) is to create a Web service (using ASP.NET Web API technology) on the Web server. Then the client would send RESTful requests to the service and the service would communicate with SQL using ADO.NET technology.

Because a prediction market is a data-driven system, my inclination would be to perform the calculations on the SQL server machine using stored procedures. This approach would allow you to deal with simultaneous requests to buy or sell shares using SQL transactions.

This entry was posted in Prediction Markets. Bookmark the permalink.