Trading applications trade-offs : Databases and low-latency

Question

Databases are required for almost every business application to store data and the transactions done on that data. The transactions typically take a time of the order of milliseconds. At the same time, in a trading application the one thing which is not at all acceptable is "latency". So, what are the trade-offs made in such applications which require an upper limit on latency?

For example, a trade has been placed by the customer, it must pass a few checks, which are stored in the database, requiring a DB fetch. Then, the trade should be passed on to an OMS/ORS or the exchange. And, at each layer, it would be required to store some sort of transaction data in the database. How should one maintain a balance between transaction persistence and low-latency?

Answer 1

Two things:

• Caching: Cache the rules in your application, so you don't need to hit the database for every trade
• Threading: Put the code that stores the transaction data in the database into another thread. Like this, you can route the trade to the exchange immediately and safe the data in the database parallel to that.

Answer 2

Now a days people use in-memory transaction system, so you cut down network latency that you get by database.

Here are some things that you can consider for low latency

• To achieve low latency in java you have to take control of GC in java, there are many ways to do that for eg pre-allocate objects(i.e use flyweight design pattern), use primitive objects - trove is very good for that, all data structure are based on primitive, Reuse object instance for eg create system wide dictionary to reduce creating new objects, very good option when reading data from stream/socket/db

-Try to reduce contention use wait-free algo( which is bit difficult), lock free algo. You can find tons of example for that

-Use in-memory computing. Memory is cheap, you can have tera byte of data in memory.

-Use mechnical sympathy - Refer lmax disruptor, excellent framework