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 largerand potentially heavierthe
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 slowthe
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 approachthat is,
sending every event to every clientrequires 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
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 ariserefresh 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
Al Roitfarb is president of investment system software
provider Investech Development and can be reached at email@example.com.
Bob Fawls is the managing partner of investment operations consulting
firm, Basis Point Group and can be reached at firstname.lastname@example.org.
Source: ©Incisive Media, Ltd. 2008