Order matcher

Introduction,
Most financial markets have moved away from the traditional open out-cry mode (with people shouting
at each other) towards an electronic system with participants sitting behind their computer screens.
Only electronic systems are considered capable of meeting today's challenges of globalisation and
rapidly increasing turn-over. This evolution is by no means limited to financial markets, but virtually
applies to all commodities which can be bought and sold.
Electronic trading has given rise to a new price-fixing mechanism. In open out-cry trading the price
derives from a process in which every seller seeks the highest bidding buyer and every buyer looks for
the seller asking for the lowest price; this process is also referred to as two-sided auction. In an
electronic exchange an order book is kept: All buy and sell orders are entered into this order book and the
prices are set according to specific rules. Bids and asks are matched and trades occur. We would like
you to design a program, called OrderMatcher, that can determine in real-time the current market price
and combine matching orders to trades. Each order has a volume and a price.

Input
There are three types of commands: BUY, SELL, PRINT and TEST. The commands should be entered
at the console (stdin) and one command is entered on each line, thus a command ends with a
newline.

BUY
"BUY instrument volume@price userid" enters a buy order with the specified volume and price.
Both price and volume are positive (> 0) integers. Example "BUY MSFT 1000@25 Michael" means
an order from Michael to buy 1000 MSFT shares at the price of 25. Orders entered should also
echo to standard out when successful.

SELL
"SELL instrument volume@price userid" enters a sell order with the specified volume and price.
Both price and volume are positive (> 0) integers. Example "SELL MSFT 500@30 Bill" means
userid Bill sell 500 MSFT shares at the price of 30. Orders entered should also echo to standard
out when successful.

PRINT
"PRINT" means that all orders in all orderbooks should be printed to the console (stdout), sorted
with the best price at the top (lowest for sell and highest for buy). The order output should follow
the format:
--- MSFT ----- BUY --BUY 100@44 Bill
BUY 300@33 Bill
--- SELL --SELL 100@55 Michael
SELL 500@67 Michael
SELL 200@88 Michael
--- DELL ----- BUY --BUY 100@44 Bill
BUY 300@33 Bill
--- SELL --SELL 100@55 Michael
SELL 500@67 Michael
SELL 200@88 Michael

PRINT instrument
"PRINT instrument" means that only the orderbook from specific instrument should be printed to the
console (stdout), sorted with the best price at the top (lowest for sell and highest for buy). The
order output should follow the format:
--- BUY --BUY 100@44 Bill
BUY 300@33 Bill
--- SELL ---

SELL 100@55 Michael

SELL 500@67 Michael
SELL 200@88 Michael

TEST
Create minimum 20 orders for 2 instruments and 2 userid's. Then create 5 orders that matches
to trades. Create 1 order that matches more than one other order (create multiple trades). During
test the created trades should be printed as interactive BUY/SELL matching would.

Trading Rules
It is a match if a buy order exist at a higher price or equal to a sell order in the order book. The
volume of both orders is reduced as much as possible. When an order has a volume of zero it is
removed. An order can match several other orders if the volume is big enough and the price is
correct. The price of the trade is computed as the order that was in the order book first (the
passive part).
The priority of the orders to match is based on the following:
1. On the price that is best for the active order (the one just entered)
2. On the time the order was entered (first come first served)
Whenever there is a trade a "TRADE instrument price@volume userid buy/sell userid buy/sell and
example:
TRADE MSFT 100@1000 Michel buy Bill sell"
If input order matches multiple orders in orderbook multiple trades should be generated.
Output should be printed out to the console (stdout).

Architecture / Object model outline

As a constraint for the supplied matching engine, follow the supplied interface specification: One
matching engine containing many orderbooks. One orderbook per instrument. Each orderbook should
have two sides (IOrderBookSide BUY and SELL) where unmatched orders reside.
IOrderBookLevel contains all orders with same price and aggregated total amount per price. Each
order is represented with IOrder where userid and amount also is available.
Bid side contains unmatched buy orders (low price), Offer side contains unmatched sell orders (high
price). Some interfaces are not reachable from input but enforces implementation. Other attributes
could be in the implementation of outlined interfaces.
public enum Side
{
BUY, SELL
}
public enum MatchingError
{

INVALIDCOMMAND, INVALIDAMOUNT, INVALIDPRICE, INVALIDINPUT //please add any

error that shows from testing your implementation
}
public interface ISystem
{
void traceError( MatchingError inErrorType, String inText ); //called on all
errors to trace into system error
}
public interface IMatchingEngine extends ISystem
{
List<IOrderBook> getOrderBooks(); //returns all orderbooks, one per instrument
List<String> getUserIds(); //active users with orders currently in matching
engine
void createOrder( String inUserId, String inInstrument, Side inSide, int
inAmount, int inPrice );
void runTest(); //should be called on TEST command
}

public interface IOrderBook

{
String getInstrument();
IOrderBookSide getOrderBookSide( Side inSide ); //access to two sides BUY and SELL
}
public interface IOrderBookSide
{
Side getSide();
Iterator<IOrderBookLevel> ascendingIterator();
Iterator<IOrderBookLevel> descendingIterator();

}
public interface IOrderBookLevel extends Comparable<IOrderBookLevel>, Iterable<IOrder>
{
int getPrice();
int getAmount(); // aggregated amount per price and side
List<IOrder> getOrders();
}
public interface IOrder
{
int getAmount();
String getCustomerId();
long getCreationTime();
}
Add any attributes needed to implementation objects or interfaces. Interfaces represents is
a minimum of needed support from the object model. If something doesn't work with your
implementation feel free to change it and/or add attributes.
There is no time constraint on the test. Any invalid system input should be handled and
traced (exceptions/format). Orders have to be consistently matched. That means that its
very important to have valid orders resting correctly on each side/sort-order and that
incoming new orders matches/removes resting orders in orderbook (correct TRADE output,
reduce of amount or removal of order). So add as many test cases needed for validating

matching (to be run on TEST command). More valid test orders shows that you correctly
validated and understand your own software contribution.