Trading front-ends handling a large number of instruments

Yesterday I prepared a client demonstration illustrating how trading front-ends can handle subscriptions to a large number of instruments.

Equity derivative and fixed income trading front-ends often display long lists of products from extensive product databases. Front-ends traditionally interact with market data platforms using the ‘publish/subscribe’ paradigm, but a subscription per instrument quickly becomes inefficient with large instrument namespaces resulting in an unwieldy number of subscriptions. Instrument lists may also change in real-time due to new product issues or changes in classification, so the client may end up subscribed to the wrong set of instruments.

A good way to handle this is for the client application to establish only a single subscription to a server-side ‘container’ entity, which auto-subscribes the client to the list constituents. As the client is subscribed to a real-time representation of the list, any item insertions or item removals result in automatic subscription changes. Additionally, the subscription can specify a dynamic window, e.g. items #10-#20, to facilitate lazy loading of data.

Caplin Xaqua includes a DSContainer data structure for this purpose, which is effectively a real-time list of instrument names. It only took an hour or so to write a DataSource adapter which generates DSContainer messages representing the real-time list, and draft alongside it another DataSource adapter providing instrument prices. Having two separate DataSource instances helps emphasise the logical separation between containers and constituent instruments. As I was demonstrating on a Windows laptop, I connected the two DataSource instances to the Windows version of Liberator, and wrote a simple client application which initiated the subscription.

The end result was a client application showing a dynamic list of many thousands of products using just a single subscription.