At my new client, one of the Tier-1 IBs on Wall Street, I am now in charge of a FX Exception Processing System. What this system does is allow FX Operations to examine and fix any FX trades which did not go through for one reason or another.
The front end is all C#/.NET, communicating with a Java trade engine using both Web Services and a home-grown XML message broker. Sybase is the database, and from the backend, connectivity is to both CLS and to SWIFTNet.
The GUI uses the Infragistics toolset, and is very grid-intensive. The real-time element is not crucial, and the trade volume is light enough so that we do not have to consider switching to the SyncFusion grid right now.
Any FX Trade Events (in this system, notification of a broken trade is called an 'event') that occur are sent from the backend to our GUI using the message broker. All FX Trades are also sent to our GUI. If the trade that comes in matches a filter criteria that is set up in one of the grids, then the trade is updated (or, in some events, the trade is deleted from the grid).
As more and more groups come on line and use our system, we will be runing into scalability issues. For example, let's say that you have a grid open that is monitoring all trades that occur today. Let's also say that no filtering criteria is set up, other than the fact that you want to look at today's trades. This means that every new trade will be inserted into the top of the grid. This is OK for now, as the trade volume is relatively light. But, more groups have expressed using our GUI. We anticipate that, by the end of the year, we might experience 10x the volume we have now.
I am going to be writing some stress-testing tools that will help us analyze the possible impact of other groups using our system. More on this later.
©2006 Marc Adler - All Rights Reserved