Saturday, August 20, 2011

A diffrent software architecture - LMAX

It was an interesting afternoon to read the article that the famous Martin Fowler had written a month ago.

It's about a different kind of architecture, how it worked and how the software engineers got to that solution of their problems. The project is about processing multiple concurrent orders and the platform had to provide low latency. The team managed to create a system that copes with 6 million transactions per second.
The strange thing is that they do it on a single-threaded application with in-memory database approach (caches).

They have tried other more-conventional approaches like multi-threading and the Actor approach but the performance of the Queue was limiting them, also the need to synchronize threads and interactions between them, context switch at CPU level was drawing performance back.

So they decided to separate input/output and processing into different modules.
Each input event gets unmarshalled and all its required pre-processing (IO operations and credit card verification operations for example) are done before hand and inserted into a the main stream that is processed by the business logic unit.

The team also create special implementations for collection classes so that they use caches better. They processed events not in a Queue approach but with a ring buffer and on it were running several processor modules - one for unmarshalling, one for backup (Journal) and Replicator and finally the Business Logic Processor. They are in a constant race and there are rules that prevent 1 from getting ahead of the other and processing a data field that isn't ready yet. This ring buffer has enormous size (20 million items)

The main idea is that CPU can process fast sequence of operations which are simple (therefore very optimized by the Java compiler), and using in-memory caches (no SQL queries), this could push the performance of a system high.

Also another gain for the team is that they don't have to cope with complex techniques like transactions, inter-thread communications etc...

I think I've just covered the basics of this software architecture approach. If you are interested enough, do visit the original article at ->

1 comment:

  1. As a whole the architecture does sound interesting, but employing event-based, single-threaded, asynchronous processing is quite standard in high performance systems. I also think that its creators are somewhat abusing the term "transaction".

    I personally stopped reading the article after gems like: "in-memory persistent state".

    By the way an interesting discussion can be found at: