Basis Point Group in the News

Need for Speed:
Advice in the Thin Client/Fat Client Debate

Dealing with Technology Vol. 4 No. 21
Feature: OPEN PLATFORM
Date: October 8th 2007

Developing a trading system is like trying to build a race car: The faster you want it to go, the larger—and potentially heavier—the engine can become. This is the dilemma of building a trading system; the need for speed versus the desire to avoid bloated software. Balancing these conflicting priorities is crucial to the success of the design.

Real-time trading systems present unique, demanding challenges to application developers. They require sub-second response times under extremely high volumes with no down time. Sell-side trading activity can range from 50,000 to 100,000 trades per day. Each trader requires immediate information on price and position to stay current with the market and react appropriately. Information latency is very costly. The trading system has a lot to do. It must respond to market price changes, maintain trader blotters, perform pre-trade verification and compliance checks, send and receive order execution status from exchanges, send and receive indications of interest (IOIs) and update blotters accordingly. Additionally, the design must often support complex algorithmic, or black-box, trading, a major consumer of computer resources. The need for zero latency dictates that the primary design and architectural challenge is speed of processing.

In architecting a client/server application, there are three choices: thin client, fat client or hybrid-muscular but fit-client. Here, the need for lightning response time proves the crucial factor in design choice. Thin client architecture is constrained by workflow. Trader A submits an order to the exchange. Thus Trader A's blotter must be updated and the outstanding order tracked until it is executed. At the same time, positions need to be updated to avoid duplicate order placement even though the order is not yet executed or confirmed. In addition, there are interested parties who should be informed of the order and its status during its lifecycle. Department heads, other traders, compliance and support personnel each require electronic notification when the order is placed, requiring that each even be propagated not only on the originating client machine but also to the other clients or servers in the network. From the users' viewpoint, their client machine is responding not only to events they originated, but also to events originated by other users, exchanges and market feeds. Two problems present themselves: notification and throughput. How should these issues be addressed?

In a three-tier architecture, the server contains the business logic and maintains the database. Given the flood of events each client must receive from the server, the challenge is how the client machines are notified of transaction events and resulting database changes. Sending XML, XBRML or HTML pages to the client is too slow—the software on the client must be optimized to quickly update trader presentation of changes in prices, orders, executed trades and positions. Notification is also an issue. Having each client machine poll the database for updates will cause the server and database to come to a grinding halt, and the alternative of refreshing the trader's view by providing a refresh button is not an option many traders are willing to endure.

The only practical alternative is to have a publish-subscribe sub-system running on the server. Using a multicast approach—that is, sending every event to every client—requires software on each client machine to determine whether that event is of interest to the user and whether that user is allowed to view that event. In a multicast approach, each client must process the message, even if it is not intended for them. In a unicast approach, or point-to-point communication, the message of the client still must be processed, hence meaningful time demands of trading require either a fat or hybrid client.

Given the need for application software on the client, the next decision is how much software is required. and what functions it should perform. Traders' blotters, positions and market data can be thought of as two-dimensional tables. Each event from the server will change one or more rows in one or more labels on the client. Two choices arise—refresh any table affected by the event or add, update or delete rows on any affected table. In either case, the software on the client must decide which cells are impacted, and have the requisite business logic to determine the values affected.

In designing a trading system, there are two competing demands. On one hand it is necessary to minimize the amount of application software across the system, in particular at the presentation layer of the client. On the other hand, it is essential to provide rapid response time on the client machine under very high-volume situations. Thin clients cannot satisfy the throughput demands of the trading system, while a fat client increases the code base and maintenance demands of the system. It is apparent that a hybrid client implementation provides the only practical solution to provide both functionality and speed.

Al Roitfarb is president of investment system software provider Investech Development and can be reached at aroitfarb@investtechnology.com. Bob Fawls is the managing partner of investment operations consulting firm, Basis Point Group and can be reached at bob.fawls@basispointgroup.com.

Source: ©Incisive Media, Ltd. 2008